commit eb6b52ff0439046f532cdcb1d50a28f344b71ccd Author: AdrianoDev Date: Sat May 9 18:19:55 2026 +0200 Initial commit: framework concettuale + design strategico PoC Stato iniziale del progetto Multi_Swarm_Coevolutive: - 00_documento_zero.md: framework concettuale (Renaissance → swarm co-evolutivo LLM, tre layer cognitivi, decisione strategica A/B/C). - coevolutive_swarm_system.md: design Filone A (sistema completo, co-evoluzione 4 popolazioni, 12-18 mesi). - poc_trading_swarm.md: design Filone B (PoC trading focalizzato, 3-4 mesi, scope semplificato). - docs/superpowers/specs/2026-05-09-decisione-strategica-design.md: decisione strategica B3 (PoC trading incrementale a 3 fasi con gate go/no-go), prodotta tramite skill brainstorming. - .gitignore: pattern Python, editor, secrets, artefatti runtime (runs.db, series/, dataset binari) non versionati. Co-Authored-By: Claude Opus 4.7 (1M context) diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..771f6f4 --- /dev/null +++ b/.gitignore @@ -0,0 +1,41 @@ +# Python +__pycache__/ +*.py[cod] +*.egg-info/ +.venv/ +venv/ +.pytest_cache/ +.mypy_cache/ +.ruff_cache/ + +# Editors / OS +.vscode/ +.idea/ +.DS_Store +*.swp +*.swo + +# Env / secrets +.env +.env.* +!.env.example +*.pem +*.key + +# Project artefacts (non versionati: troppo grandi o rigenerabili) +runs.db +runs.db-journal +runs.db-wal +runs.db-shm +series/ +*.parquet +*.feather +data/ +checkpoints/ +logs/ +*.log + +# Build / dist +build/ +dist/ +*.egg diff --git a/00_documento_zero.md b/00_documento_zero.md new file mode 100644 index 0000000..b6c8617 --- /dev/null +++ b/00_documento_zero.md @@ -0,0 +1,323 @@ +# Documento Zero — Da Renaissance a Swarm Co-Evolutivo + +**Autore**: Adriano Dal Pastro +**Data**: Maggio 2026 +**Status**: Sintesi concettuale di partenza +**Versione**: 0.1 +**Documenti correlati**: +- `coevolutive_swarm_system.md` (sistema completo) +- `poc_trading_swarm.md` (proof of concept trading) + +--- + +## 1. Scopo di questo documento + +Questo è il **documento zero** della serie. Non descrive un'implementazione, descrive il **ragionamento di partenza** che ha portato all'architettura proposta negli altri due documenti. + +Lo scopo è fissare il framework concettuale, così che quando riprendiamo il lavoro tra giorni o settimane il contesto non vada perso. Risponde alla domanda: *perché stiamo facendo questo, e perché in questo modo specifico?* + +--- + +## 2. Il punto di partenza: Renaissance Technologies + +### 2.1 Cosa è Renaissance + +Hedge fund fondato 1978 da Jim Simons (matematico puro, ex code-breaker NSA, premio Oswald Veblen 1976 in geometria). Sede Long Island. Staff composto principalmente da PhD in fisica, matematica, statistica, signal processing — **zero economisti tradizionali**. Simons è morto a maggio 2024. + +### 2.2 La filosofia opposta a LTCM + +| LTCM | Renaissance | +|---------------------------------|--------------------------------------| +| Parte da teoria (Black-Scholes) | Parte dai dati | +| Cerca conferme | Cerca anomalie | +| Modello statico | Modello che si aggiorna ogni giorno | +| Crolla quando realtà ≠ teoria | Cambia quando realtà cambia | + +### 2.3 Come opera + +- Non cerca pattern ovvi (spariscono subito quando tutti li vedono) +- Cerca decine di anomalie sottili, ognuna con edge minuscolo ma statisticamente significativo. Sommate → edge stabile e potente. +- Sistema 100% automatico. Nessun umano decide trade. Simons: "umano = variabile non controllabile". +- Ingerisce terabyte di dati al giorno. Scarta pattern morti, incorpora nuovi. +- Pattern usati negli '80 oggi non funzionano più — quando un pattern diventa noto, sparisce. + +### 2.4 Numeri (Medallion Fund, fondo interno) + +- ~66% lordo annuo per 30+ anni consecutivi +- ~39% netto dopo le fee mostruose (5% management + 44% performance) +- Mai un anno in perdita. Compreso 1998 mentre LTCM bruciava 5 miliardi +- $100 nel 1988 → $8.4 miliardi oggi (vs $2400 in S&P) +- Confronto con Buffett: Buffett 20%/anno = "il migliore al mondo". Simons 3x più di Buffett, per 2x più anni + +--- + +## 3. La domanda critica: cosa è replicabile? + +### 3.1 Cosa NON è replicabile + +Il 66% lordo del Medallion non viene da "matematici geniali". Viene da fattori strutturali che retail non può replicare: + +- **Latency e infrastruttura**: co-location, feed di mercato grezzi, esecuzione sub-millisecondo. Il 70% dell'edge sui pattern intraday è banalmente velocità. +- **Capacity cap**: Medallion è chiuso a circa $10B perché l'edge non scala. Le anomalie sottili che sfruttano si saturano. Le strategie vere di Renaissance non solo non sono pubbliche — sono *inutili* a chi le rendesse pubbliche. +- **Dataset proprietari**: decenni di tick data puliti, dati alternativi, e soprattutto un team di 100+ ricercatori che fa SOLO data cleaning. Il loro vero IP è la qualità del dato, non il modello. +- **Risk management con leva istituzionale**: prime broker relationship, dimensioni di hedging fuori portata retail. + +Replicare Renaissance retail è come voler replicare TSMC con una stampante 3D. Non è una questione di intelligenza, è di scala. + +### 3.2 Cosa È replicabile (tradotto in principi operativi) + +I principi filosofici di Renaissance, applicati al contesto LLM-agent + retail: + +1. **"Cerca anomalie, non conferme"** → il prompt non chiede all'agente di valutare se "le condizioni sono buone per X", chiede di identificare regimi in cui la struttura dei dati devia da pattern storici, e adattare la strategia. + +2. **"Edge piccoli sommati"** → su crypto retail un singolo edge da 50bp/trade è realistico, 500bp no. L'architettura deve permettere molte posizioni indipendenti piccole. Renaissance fa migliaia di trade/giorno proprio per questo. + +3. **"Modello che si aggiorna"** → per un sistema LLM questo è sottile: il modello *non si aggiorna* tra una chiamata e l'altra. L'aggiornamento deve essere fuori dal modello, in un layer di state/memory. + +4. **"Umano = variabile non controllabile"** → l'analogo è che *l'LLM stesso* è una variabile non controllabile (temperatura, bias di addestramento). L'LLM deve generare ipotesi, ma le decisioni execute/no-execute devono essere filtrate da regole deterministiche. + +### 3.3 Il vero takeaway: survivorship bias + +La cosa più importante che Simons ripeteva: per ogni Renaissance esistono centinaia di fondi quant chiusi silenziosamente. La differenza spesso non è il modello, è la **disciplina di spegnere strategie quando l'edge svanisce**. Avere metriche oggettive di "questa strategia è morta" che fanno killare il branch automaticamente, senza decisioni emotive. + +--- + +## 4. Lo shift mentale: dagli umani agli agenti illimitati + +### 4.1 La differenza categoriale + +Renaissance ha 300 ricercatori. Con LLM agents si possono istanziare 3000 agenti in parallelo a costo marginale quasi zero. Questo non è "più della stessa cosa", è una **categoria diversa di problema**. + +Renaissance deve essere selettiva su quali ipotesi testare perché ogni PhD è caro e lento. Con LLM agents no. Si può permettere di testare ipotesi *stupide*, perché 99.9% di stupide + 0.1% di geniali > 100% di "ragionevoli". + +Cambia tutto il framework. Le strategie quant tradizionali partono da un'ipotesi economica/strutturale e cercano evidenza. Si può fare il contrario: **brute force di ipotesi generate da LLM, filtrate da realtà**. + +### 4.2 Il salto verso l'evoluzione + +Se hai migliaia di agenti che generano ipotesi, il problema diventa: come scoprire quali stili cognitivi producono ipotesi migliori? Risposta: **lascia che siano evolutivamente selezionati**. Non scrivi tu il prompt ottimale, lo scopri attraverso pressione selettiva. + +Questo è il salto concettuale: passare da prompt engineering (artigianato umano) a prompt evolution (ricerca automatica nello spazio dei prompt). + +### 4.3 Il salto ulteriore: linguaggio emergente + +Se gli agenti devono comunicare tra loro, il linguaggio naturale umano è probabilmente subottimale. È stato ottimizzato per vincoli umani (vocal tract, memoria di lavoro limitata, ambiguità sociale utile) che non si applicano agli LLM. + +Si può co-evolvere il **protocollo di comunicazione** insieme agli agenti. Il risultato è un sistema dove agenti e linguaggio si adattano insieme — analogo all'evoluzione del linguaggio scientifico umano (notazione vettoriale + pensiero vettoriale evolvono insieme), ma compresso in giorni invece che millenni. + +--- + +## 5. L'architettura emergente: tre layer cognitivi + +Dalla riflessione su Renaissance + LLM swarm + evoluzione, emerge un'architettura specifica con tre ruoli funzionali distinti. + +### 5.1 Hypothesis Layer + +**Ruolo**: generazione creativa di ipotesi su anomalie. Alta temperatura, stili cognitivi diversi, ricerca esplorativa. + +**Diversità cognitiva intenzionale**: agenti con prompt che li fanno "pensare come un fisico", "come un biologo evolutivo", "come uno storico", "come un meteorologo". Stili diversi → ipotesi diverse. + +### 5.2 Falsification Layer + +**Ruolo**: testare rigorosamente. Bassa temperatura, focus su statistica deterministica. + +**Funzione critica**: questo NON è LLM puro. È codice tradizionale (backtesting, walk-forward, multiple testing correction) orchestrato da LLM. L'LLM non deve mai *valutare* se una strategia funziona, deve *eseguire* test rigorosi e leggere risultati numerici. + +### 5.3 Adversarial Layer + +**Ruolo**: red team epistemico. Cerca data snooping, lookahead bias, regime fragility, crowding. Paranoia strutturale. + +**Per ogni strategia che sopravvive**, l'agente fa l'avvocato del diavolo: "perché questa strategia *deve* fallire?". Solo strategie che sopravvivono al red team passano alla fase successiva. + +### 5.4 Perché tre e non uno + +I tre ruoli hanno requisiti cognitivi opposti: +- Hypothesis vuole creatività, alto temperature +- Falsification vuole rigore, low temperature +- Adversarial vuole paranoia, medium temperature + +Un singolo agente non può fare tutti e tre bene. Specializzarli e farli collaborare produce risultati qualitativamente migliori, e abilita evoluzione separata di ogni nicchia. + +--- + +## 6. I tre filoni che si sono sviluppati + +Dal framework concettuale base si sono sviluppati tre filoni, ognuno documentato (o da documentare) separatamente. + +### 6.1 Filone A — Sistema completo + +Co-evoluzione di **quattro popolazioni**: tre layer cognitivi + il protocollo di comunicazione. + +**Caratteristiche**: +- Co-evolution multi-species +- Speciation (NEAT-style) +- Idiom emergence nel protocollo +- Register specialization per layer +- Tier multi-model (Claude + Qwen + Llama via OpenRouter) come risorsa di diversità cognitiva +- Human-in-the-loop calibration + +**Portata**: 12-18 mesi a impegno significativo. Sistema generale applicabile a multipli domini (trading, offerte commerciali, code review). + +**Documento di riferimento**: `coevolutive_swarm_system.md` + +### 6.2 Filone B — PoC trading focalizzato + +Versione semplificata per validare empiricamente il concetto prima di committere al sistema completo. + +**Caratteristiche**: +- Solo Hypothesis layer evolve (Falsification e Adversarial hand-crafted) +- Protocollo fisso (no co-evolution del linguaggio) +- Focus su trading BTC/ETH con storico multi-anno +- Baseline Random Forest per anti-illusion check +- Decision triggers oggettivi per go/iterate/pivot + +**Portata**: 3-4 mesi. Costo ~$2-4K LLM. + +**Documento di riferimento**: `poc_trading_swarm.md` + +### 6.3 Filone C — Applicazioni non-trading + +Stesso framework architetturale applicato a domini con ground truth diverso: +- Generazione offerte commerciali Tielogic (dataset implicito: offerte passate firmate vs no) +- Code review automatico (dataset: PR storiche con bug noti) +- Documentazione Swagger (fitness: copertura + qualità) +- Scrittura documentazione tecnica + +**Portata**: parallelizzabile con Filone A. Validazione che il sistema generalizzi. + +**Documento di riferimento**: da scrivere se si decide di approfondire. + +--- + +## 7. Le quattro idee non-ovvie + +Sintesi delle intuizioni emerse durante la riflessione, in ordine di profondità: + +### 7.1 Diversità cognitiva via tier multi-model + +Non è solo "tier economici come compromesso". È che modelli diversi (Claude, Qwen, Llama, DeepSeek) hanno bias di addestramento diversi e producono ipotesi qualitativamente diverse sullo stesso dato. Per ricerca esplorativa è oro. Manterrei il multi-tier *anche se Anthropic dimezzasse i prezzi domani*. + +### 7.2 Il protocollo di comunicazione come risorsa evolvibile + +Forzare gli agenti a comunicare in linguaggio naturale è una scelta arbitraria, probabilmente subottimale. Co-evolvere protocollo + agenti significa che i pattern cognitivi che il sistema scopre dipendono da quali pensieri sono *cheap da esprimere*. E il protocollo evolve per rendere cheap i pensieri che si rivelano utili. Loop di co-adattamento, come grammatica e pensiero scientifico nelle culture umane. + +### 7.3 Vincolo di leggibilità non opzionale + +Senza vincoli, gli agenti convergono a protocolli incomprensibili. Per safety, audit, compliance, debugging — la fitness del protocollo deve includere `human_unreadability_score` con λ esplicito. Il sistema vive sul Pareto front efficienza/interpretabilità, scelto consapevolmente. + +### 7.4 Survivorship bias narrativo + +Sia chiaro: Renaissance è UN risultato di una distribuzione di tentativi. Per ogni Renaissance ci sono centinaia di fondi quant morti silenziosamente. Lo stesso vale per i sistemi LLM-based: la maggior parte non funzionerà. Il PoC esiste proprio per essere un esperimento *honestly designed to fail* se l'idea non regge. La baseline non-LLM (Random Forest) è il guardrail anti-illusione. + +--- + +## 8. Le quattro trappole strutturali + +In ordine di gravità, le trappole che possono distruggere qualsiasi versione del sistema: + +### 8.1 Goodhart's Law su steroidi + +L'evoluzione è una macchina ottimizzatrice cieca e troverà *qualunque* exploit della fitness function. Mitigazione: fitness multi-livello, human-in-the-loop, audit periodici dei top performer. + +### 8.2 Multiple testing massiccio + +Con migliaia di ipotesi testate, false scoperte a valanga. Mitigazione: Deflated Sharpe Ratio (Bailey & López de Prado), Bonferroni aggressiva, hold-out set finale intoccabile. + +### 8.3 Communication degeneration + +Senza vincoli, agenti convergono a comunicazione minimale e incomprensibile. Mitigazione: penalty leggibilità, parser strict, audit umano, italian rendering automatico. + +### 8.4 Convergenza prematura / collasso di diversità + +Senza speciation e novelty bonus, dopo 50 generazioni saturi su un ottimo locale. Mitigazione: speciation, novelty search, immigrazione random periodica, island model. + +--- + +## 9. Decisione strategica: tre opzioni + +Le opzioni concrete davanti, in ordine di rischio crescente: + +**Opzione C — Research dive** (1-2 mesi) +- Paper review approfondito (PromptBreeder, NEAT, MAP-Elites, emergent communication) +- Proof-of-concept minimo (1 layer, 1 popolazione, protocol semplice) +- Output: decisione informata se vale tutto + +**Opzione B — Smart spike** (3-4 mesi) ← **scelta preferita per partire** +- PoC trading completo (`poc_trading_swarm.md`) +- Infrastruttura riutilizzabile +- Output: validazione empirica + infrastruttura per espansione + +**Opzione A — Big bet** (12-18 mesi) +- Sistema completo (`coevolutive_swarm_system.md`) +- Co-evolution piena, applicazioni multi-dominio +- Output: sistema di ricerca/produzione, possibile paper + +**Razionale per partire da B**: minimizza opportunity cost rispetto agli altri progetti (Tielogic, robotics, OptionScalping), produce infrastruttura riutilizzabile, dà criteri oggettivi per decidere se procedere con A. + +--- + +## 10. Perché questo progetto, perché ora + +### 10.1 Posizione strategica + +Adriano è in una posizione strana e fortunata: +- Background ingegneristico solido (C, C++, C#, Python da 30 anni) +- Use case reali multipli (trading, offerte commerciali, robotica Tielogic) +- Motivazione applicativa (non puramente accademica) +- Familiarità con LLM tooling (Claude Code attivo nel workflow) +- Capacità di lavorare full-stack (dal Rust backend al frontend React) + +### 10.2 Stato del campo + +Il filone "evolved structured communication languages for LLM multi-agent systems with interpretability constraints" non è saturo. La community è bloccata su due estremi: JSON+natural language (boring), o emergent communication su small models (non scalato a LLM moderni). C'è spazio per contributi reali. + +### 10.3 Tempistica delle infrastrutture + +Maggio 2026: i prezzi dei modelli sono scesi abbastanza da rendere economicamente fattibile un GA con migliaia di chiamate. OpenRouter offre routing multi-model trasparente. Anthropic ha prompt caching aggressivo. Tooling open-source maturo (DEAP, DSPy, TextGrad). **Tre anni fa questo progetto sarebbe stato troppo costoso. Tre anni avanti potrebbe essere già commoditizzato**. + +### 10.4 Honest assessment + +Detto tutto questo: il progetto è ambizioso, non garantito, e in competizione di tempo con altri progetti reali (Tielogic clienti, OptionScalping, robotics). La via responsabile è l'**Opzione B**: validare con il PoC, decidere a posteriori se vale espandere. Big bet su sistema completo solo dopo evidenza empirica positiva. + +--- + +## 11. Stato del lavoro al 9 maggio 2026 + +**Completato**: +- Framework concettuale (questo documento) +- Design completo sistema (`coevolutive_swarm_system.md`) +- Design completo PoC (`poc_trading_swarm.md`) + +**Decisioni aperte prima di partire**: +1. Quale opzione (A/B/C)? +2. Se B, quale dominio iniziale (trading vs offerte commerciali)? +3. Hardware locale vs cloud? +4. Budget LLM iniziale committed? +5. Cadenza review umana sostenibile? + +**Prossimi passi se si decide GO sul PoC (Opzione B)**: +- Settimane 1-3: setup + dataset (vedi roadmap PoC sez. 11) +- Decisioni infrastruttura (data provider, storage, compute) +- Cap budget chiaro e milestone bi-settimanali + +--- + +## 12. Tracciabilità della catena di ragionamento + +Per riferimento futuro, questa è la sequenza logica che ha portato all'architettura proposta: + +1. **Renaissance come modello**: dati > teoria, anomalie > conferme, automatico > umano +2. **Cosa è replicabile**: principi filosofici sì, infrastruttura no +3. **LLM agents shift**: scala diversa rende possibile brute force di ipotesi +4. **Tre layer cognitivi**: Hypothesis + Falsification + Adversarial come specializzazione funzionale necessaria +5. **Evoluzione genetica**: scoprire prompt ottimali invece di scriverli +6. **Co-evolution multi-popolazione**: i tre layer evolvono insieme +7. **Linguaggio evolutivo**: il protocollo di comunicazione è artefatto evolvibile +8. **Tier multi-model**: diversità cognitiva + economia +9. **Vincoli di leggibilità**: non opzionali per safety/audit +10. **PoC come deviazione strategica**: validare prima di committere full + +Ogni step è un pezzo del ragionamento che vale la pena ricordare. Se uno step si rivela sbagliato, gli step successivi vanno rivisti. + +--- + +*Documento da aggiornare se la direzione strategica cambia. Versione 0.1 — pre-implementazione.* diff --git a/coevolutive_swarm_system.md b/coevolutive_swarm_system.md new file mode 100644 index 0000000..7c1b658 --- /dev/null +++ b/coevolutive_swarm_system.md @@ -0,0 +1,660 @@ +# Sistema Co-Evolutivo Multi-Agente con Linguaggio Emergente + +**Autore**: Adriano Dal Pastro +**Data**: Maggio 2026 +**Status**: Design document — pre-implementazione +**Versione**: 0.1 + +--- + +## 1. Executive Summary + +Sistema di ricerca quantitativa basato su **co-evoluzione di quattro popolazioni**: tre layer cognitivi (Hypothesis / Falsification / Adversarial) e un protocollo di comunicazione che evolve insieme agli agenti. L'obiettivo non è "un trading bot più intelligente", ma un'**architettura cognitiva ecologica** capace di scoprire pattern e concetti non programmati esplicitamente. + +L'introduzione di un **tier multi-model** (Anthropic Claude tramite API + modelli economici tipo Qwen via OpenRouter) cambia radicalmente l'economia del sistema: rende fattibili popolazioni 5-10x più grandi e numero di generazioni 3-5x più alto a parità di budget, abilitando regimi evolutivi prima irraggiungibili per progetti retail. + +**Domini di applicazione iniziali**: +- Trading derivati crypto (Deribit options, Hyperliquid perps) — caso primario +- Generazione offerte commerciali Tielogic — caso secondario, ad alto ROI immediato +- Code review e generazione documentazione — caso terziario + +--- + +## 2. Architettura del Sistema + +### 2.1 Visione d'insieme + +``` + ┌─────────────────────────┐ + │ PROTOCOL GENOME (PG) │ + │ - syntax (fixed) │ + │ - vocabulary (evolves) │ + │ - idioms (emerge) │ + │ - registers (specialize)│ + └────────────┬────────────┘ + │ specifies + ▼ + ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ + │ HYPOTHESIS │ │ FALSIFICATION│ │ ADVERSARIAL │ + │ SWARM │◄──►│ SWARM │◄──►│ SWARM │ + │ │ │ │ │ │ + │ K_h agents │ │ K_f agents │ │ K_a agents │ + └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ + │ │ │ + └───────────────────┼───────────────────┘ + ▼ + ┌─────────────────────┐ + │ SHARED ENVIRONMENT │ + │ - market data │ + │ - backtest engine │ + │ - message bus │ + │ - audit log │ + └─────────────────────┘ + │ + ▼ + ┌─────────────────────┐ + │ FITNESS COMPUTATION│ + │ - per-agent │ + │ - per-team │ + │ - per-protocol │ + └─────────────────────┘ +``` + +### 2.2 Le quattro popolazioni co-evolventi + +#### 2.2.1 Hypothesis Swarm + +**Ruolo**: generare ipotesi su anomalie di mercato. Alta temperatura, stili cognitivi diversi, ricerca esplorativa. + +**Genoma**: +```python +@dataclass +class HypothesisAgentGenome: + system_prompt: str # ruolo cognitivo + feature_access: list[str] # subset feature disponibili + temperature: float # 0.7 - 1.3 tipico + top_p: float + model_tier: ModelTier # vedi sez. 4 + lookback_window: int # giorni di storico visibili + cognitive_style: str # "physicist", "biologist", "historian"... + protocol_dialect_bias: dict # preferenze su verbi del protocollo +``` + +**Output atteso**: ipotesi formalizzate nel protocollo, tipo: +``` +PROPOSE_HYPOTHESIS( + pattern="vol_skew_pre_FOMC", + conditions=[regime=normal, days_to_event<=7], + predicted_effect=skew_widening, + confidence=0.6, + rationale_ref=#analysis_142 +) +``` + +#### 2.2.2 Falsification Swarm + +**Ruolo**: testare rigorosamente le ipotesi. Bassa temperatura, focus su statistica, walk-forward, multiple testing correction. + +**Genoma**: +```python +@dataclass +class FalsificationAgentGenome: + system_prompt: str + statistical_test_preferences: list[str] # ["bonferroni", "BH", "white_reality_check"] + rigor_level: float # quanto è severa la soglia + walk_forward_config: WalkForwardConfig + temperature: float # 0.1 - 0.4 tipico + model_tier: ModelTier +``` + +**Caratteristica importante**: il falsification layer NON valuta soggettivamente. Esegue test deterministici e li interpreta. Questo lo rende perfetto per modelli economici. + +#### 2.2.3 Adversarial Swarm + +**Ruolo**: red team epistemico. Cerca data snooping, lookahead bias, regime fragility, crowding. Paranoia strutturale. + +**Genoma**: +```python +@dataclass +class AdversarialAgentGenome: + system_prompt: str + attack_vocabulary: list[str] # tipi di attacchi noti + paranoia_level: float # quanto aggressivo + historical_failure_db: str # quali falsi positivi ricordare + temperature: float # 0.5 - 0.9 tipico + model_tier: ModelTier +``` + +#### 2.2.4 Protocol Genome + +**Ruolo**: meta-popolazione. Non è un agente, è la specifica del linguaggio che gli agenti usano. + +**Genoma**: +```python +@dataclass +class ProtocolGenome: + syntax: Grammar # FISSA: S-expr like + vocabulary: dict[str, VerbDefinition] # EVOLVE + idioms: list[Macro] # EMERGONO + registers: dict[Layer, VocabSubset] # EMERGONO + type_system: TypeSchema # EVOLVE lentamente + confidence_grammar: ConfidenceSchema # come esprimere uncertainty +``` + +**Sintassi base** (immutabile per garantire parsabilità): +``` +expression := (verb arg*) +arg := atom | expression | reference +reference := #identifier +atom := number | string | symbol | typed_value +typed_value := +``` + +**Vocabolario iniziale** (15-20 verbi base, poi evolve): +``` +PROPOSE_HYPOTHESIS, ASSERT_EVIDENCE, CHALLENGE, +REFINE, CITE, COMMIT, REJECT, QUERY, +EXPRESS_UNCERTAINTY, REGIME_CONDITION, FEATURE_DRIFT, +SAMPLE_REQUEST, REPLAY_REQUEST, BIND_VARIABLE, REPORT_RESULT +``` + +--- + +## 3. Meccanismi Evolutivi + +### 3.1 Operatori genetici per agenti + +**Mutazione del system prompt**: +- Strategia A (LLM-as-mutator): un modello tier-medio riscrive il prompt con istruzione "modifica un aspetto cognitivo mantenendo intent". Output sempre coerente. +- Strategia B (structured): il prompt è scomposto in sezioni (role, context, instructions, constraints, examples, output_format), mutazione opera dentro una sezione. +- **Scelta**: ibrido B+C, per garantire validità sintattica e ricchezza semantica. + +**Crossover di feature set**: classico, 50/50 da due parent. + +**Mutazione di iperparametri**: gaussiana su temperature/top_p, discreta su model_tier (raramente). + +**Mutazione di model_tier**: rara (5%), perché cambia significativamente costi e capability. Vedi sez. 4. + +### 3.2 Operatori genetici per protocollo + +**Mutazione di vocabolario**: +- Add verb: il sistema propone nuovo verbo basato su pattern di uso (frasi ricorrenti che meriterebbero verbo dedicato) +- Remove verb: verbi sotto soglia di uso vengono deprecati +- Modify schema: aggiungi/rimuovi argomenti di un verbo esistente +- Rename: alias semantici emergono + +**Idiom emergence** (la parte più interessante): +- Il sistema rileva sequenze di verbi che appaiono frequentemente insieme con alta correlazione a fitness team +- Queste sequenze diventano "idioms" — macro che possono essere espanse o usate come unità +- Esempio: `[CHALLENGE + REFINE + RE-CHALLENGE]` ricorrente → idiom `STRESS_TEST(target=#X, depth=3)` + +**Register specialization**: +- Tracking di quali verbi vengono usati prevalentemente da quale layer +- Se un verbo è usato >80% da un layer specifico, viene marcato come "register-specific" +- Riduce overhead cognitivo: un agente non deve imparare verbi che non userà + +### 3.3 Selezione e riproduzione + +**Selection method**: tournament selection (k=5), più robusto di roulette wheel su fitness rumorose. + +**Speciation** (NEAT-style): +- Cluster agenti per similarità semantica del prompt (embedding + cosine distance) +- Fitness sharing dentro la specie +- Effetto: nicchie cognitive diverse coesistono (mean-reversion, momentum, vol-arb, ecc.) + +**Reproduction mix**: +- 60% crossover tra parent della stessa specie +- 25% mutazione singolo parent +- 10% inter-species crossover (rare, può produrre breakthrough) +- 5% immigrazione (agenti random nuovi, anti-stagnazione) + +**Elitismo**: top 5% per popolazione sopravvive non modificato. + +### 3.4 Co-evolution dynamics + +Le quattro popolazioni evolvono in **frequenze diverse**: + +| Popolazione | Frequenza evoluzione | Motivo | +|---------------|----------------------|-------------------------------------------| +| Hypothesis | Ogni generazione | Esplorazione massiva | +| Falsification | Ogni generazione | Adattamento ai nuovi tipi di ipotesi | +| Adversarial | Ogni 2 generazioni | Più stabile, paranoia richiede consistenza | +| Protocol | Ogni 5 generazioni | Cambiamenti lenti, evita instabilità | + +**Razionale**: il protocollo cambia lentamente perché è il "terreno comune". Cambi rapidi del protocollo destabilizzano tutte le popolazioni che ci comunicano. È analogo a come la grammatica evolve più lentamente del lessico nelle lingue umane. + +--- + +## 4. Tier Multi-Model: l'innovazione economica + +### 4.1 Il problema dei costi + +Con solo Claude Sonnet/Opus, una run completa di 500 generazioni costa $30-50K. Fattibile ma limitante: non puoi sperimentare liberamente, ogni run è un evento. + +### 4.2 La soluzione: stratificazione per ruolo cognitivo + +Non tutti gli agenti hanno bisogno di un modello frontier. Diversi ruoli hanno diversi requisiti cognitivi. + +**Tier definiti**: + +| Tier | Modello esempio | Provider | Costo (in/out per Mtok) | Use case | +|--------|-----------------------------------|-------------|-------------------------|-----------------------------------------| +| Tier-S | Claude Opus 4.7 | Anthropic | $15 / $75 | Hypothesis creativi, ricerca breakthrough| +| Tier-A | Claude Sonnet 4.6 | Anthropic | $3 / $15 | Adversarial sofisticati, reasoning denso | +| Tier-B | Qwen3-Max / DeepSeek-V3 | OpenRouter | $0.5-1 / $1-3 | Falsification statistica, executors | +| Tier-C | Qwen3-30B / Llama 3.3 70B | OpenRouter | $0.1-0.3 / $0.3-0.6 | Massa Hypothesis esplorativi, mutators | +| Tier-D | Modelli small open-source | OpenRouter | $0.05-0.1 | Validation parsing, formatting checks | + +**Nota sui prezzi**: i numeri sopra sono indicativi al maggio 2026, ma OpenRouter aggiorna continuamente — verificare prima di run reali. La gerarchia di costi è stabile, le cifre esatte fluttuano. + +### 4.3 Allocazione cognitiva per layer + +| Layer | Tier-S | Tier-A | Tier-B | Tier-C | Tier-D | +|---------------|--------|--------|--------|--------|--------| +| Hypothesis | 5% | 15% | 30% | 50% | 0% | +| Falsification | 0% | 10% | 60% | 30% | 0% | +| Adversarial | 10% | 40% | 40% | 10% | 0% | +| Protocol mut. | 0% | 30% | 50% | 20% | 0% | +| Validators | 0% | 0% | 0% | 0% | 100% | + +**Razionale per layer**: + +- **Hypothesis** beneficia di diversità cognitiva. Pochi Tier-S per breakthrough rari, massa Tier-C per esplorazione ampia. Modelli diversi hanno bias cognitivi diversi (Qwen vs Claude vs Llama producono ipotesi qualitativamente diverse — questo è feature, non bug). +- **Falsification** è principalmente esecuzione di test statistici e interpretazione di numeri. Tier-B/C bastano. Errori qui sono più costosi però (falso negativo = strategia cattiva passa) → nessun Tier-D. +- **Adversarial** richiede reasoning sofisticato (riconoscere lookahead bias subtle, regime dependency). Più peso su Tier-A/B. +- **Validators**: parser, formattatori, basic checks → Tier-D è perfetto, costo trascurabile. + +### 4.4 Cross-model diversity come risorsa + +Punto **non ovvio ma importante**: avere modelli da provider diversi nelle popolazioni produce *diversità cognitiva intrinseca*. Claude e Qwen e Llama sono stati addestrati su corpus diversi, con RLHF diverse, con bias diversi. Per ricerca esplorativa questo è oro. + +Esempio concreto: su ipotesi crypto, Qwen tende a privilegiare considerazioni di market microstructure che vengono dalla sua forte esposizione a contenuti tech cinesi. Claude tende a essere più cauto sulle estrapolazioni statistiche. Llama produce associazioni più libere. Mescolarli porta a portafoglio di ipotesi più ricco di quanto produrrebbe una sola famiglia di modelli, anche se tutti i modelli fossero al top tier. + +Questo è un argomento *non economico* per il multi-tier. Vale la pena anche se Anthropic abbassasse drasticamente i prezzi. + +### 4.5 Economia rivista + +Con tier multi-model: + +- Generazione singola con popolazione K=300 (vs K=180 originale): ~$15-25 (vs $50-80) +- 500 generazioni: $7-12K (vs $25-40K) +- Risparmio: ~3x su scala operativa +- **Oppure** a parità di budget: K=900, 1500 generazioni → regime evolutivo qualitativamente diverso + +A regime evolutivo "alto" (K grandi, generazioni numerose) si manifestano fenomeni che a regime basso non appaiono: speciation stabile, idiom emergence frequente, breakthrough rari ma cumulativi. + +### 4.6 Considerazioni operative su OpenRouter + +**Vantaggi**: +- Singolo endpoint per N modelli, switching facile +- Fallback automatico se un provider è giù +- Pricing trasparente, no enterprise contracts richiesti +- Rate limits aggregati ragionevoli + +**Svantaggi**: +- Latenza variabile (modelli ospitati da provider diversi) +- Quality fluctuations (alcuni provider hanno hosting subottimo) +- Mancanza di prompt caching per modelli non-Anthropic (Claude rimane vantaggio per long-context) +- Privacy policy variabili per modello (verificare per dati sensibili — non un problema per dati di mercato pubblici) + +**Configurazione consigliata**: +```python +class ModelRouter: + def call(self, agent_genome, messages): + tier = agent_genome.model_tier + if tier == ModelTier.S: + return anthropic_client.call("claude-opus-4-7", messages) + elif tier == ModelTier.A: + return anthropic_client.call("claude-sonnet-4-6", messages) + elif tier == ModelTier.B: + return openrouter.call("qwen/qwen3-max", messages) + elif tier == ModelTier.C: + return openrouter.call("qwen/qwen3-30b-instruct", messages) + elif tier == ModelTier.D: + return openrouter.call("meta-llama/llama-3.3-8b", messages) +``` + +**Fallback policy**: se Tier-C fallisce 3 volte di fila (timeout, malformed output), promuovi temporaneamente a Tier-B per quell'agente. Loggato per evitare gaming evolutivo della failure rate. + +--- + +## 5. Fitness Function (la parte critica) + +### 5.1 Tre livelli di fitness + +**Per agent** (selezione intra-popolazione): +``` +agent_fitness = quality_of_contributions + - communication_overhead + - cost_penalty (proporzionale al tier usato) + - genealogy_redundancy_penalty +``` + +Il `cost_penalty` è cruciale: senza di esso, l'evoluzione tende a promuovere Tier-S su tutto. Con esso, gli agenti devono "guadagnarsi" il diritto a tier costosi mostrando contribuzioni proporzionali. + +**Per team** (combinazioni h+f+a che funzionano insieme): +``` +team_fitness = OOS_alpha_discovered + + bug_caught_rate + - time_to_consensus + - false_positive_rate + - total_cost_per_episode +``` + +**Per protocol** (vocabolario/idiomi che meritano di rimanere): +``` +protocol_fitness = avg_team_fitness_using_this_protocol + / avg_message_length + - λ * human_unreadability_score + + idiom_compression_ratio + - vocabulary_bloat_penalty +``` + +### 5.2 Human-in-the-loop calibration + +**Non opzionale**. Ogni 20 generazioni: +- Sample top 10 ipotesi → judgment umano (insight reale vs gameificazione) +- Sample top 10 idiomi protocol → judgment umano (concetto sensato vs gibberish funzionale) +- Sample top 5 attacchi adversarial → judgment umano (argument valido vs sofisma) + +Il giudizio umano retroattivamente penalizza pattern fraudolenti. Questo è il **vincolo che impedisce divergenza creativa-ma-inutile**. + +### 5.3 Anti-gaming measures + +**Trappole noti e mitigazioni**: + +| Trappola | Manifestazione | Mitigazione | +|---------------------------|-----------------------------------------------|------------------------------------------------| +| Communication degeneration| Messaggi minimali tipo "42" | Penalty su brevità eccessiva + parser test | +| Layer collapse | Popolazioni convergono a strategie omogenee | Speciation forte, novelty bonus, task rotation| +| Protocol overfitting | Idiomi specifici al task corrente | Rotation di task durante evoluzione | +| Adversarial collusion | Layer si rinforzano in modo perverso | Fitness globale del team su PnL OOS reale | +| Tier inflation | Tutti gli agenti migrano a Tier-S | Cost penalty proporzionale nel agent_fitness | +| Backtest exploit | Sfruttare bug del backtest engine | Audit periodici dei top performer + adversarial test sintetici | + +--- + +## 6. Stack Tecnico + +### 6.1 Linguaggi e framework + +- **Backbone Python** per orchestrazione, GA, agent management (DEAP framework) +- **Rust** per backtest engine (performance critica, deterministica) +- **PostgreSQL + pgvector** per genomi, embedding, audit log +- **Redis** per message bus tra agenti durante episodio +- **Docker Compose** per deployment locale +- **Anthropic SDK** + **OpenRouter API** via httpx +- **Ray** o **asyncio + aiohttp** per parallelizzazione agenti + +### 6.2 Storage schema (essenziale) + +```sql +-- Genomi con genealogia completa +CREATE TABLE agent_genomes ( + id UUID PRIMARY KEY, + layer TEXT NOT NULL, + generation INT NOT NULL, + species_id UUID, + parent_ids UUID[], + genome_data JSONB, + embedding VECTOR(1536), + fitness FLOAT, + created_at TIMESTAMPTZ +); + +CREATE TABLE protocol_genomes ( + id UUID PRIMARY KEY, + generation INT, + vocabulary JSONB, + idioms JSONB, + fitness FLOAT +); + +-- Audit log dei messaggi (cresce velocemente, considerare retention) +CREATE TABLE message_log ( + id UUID PRIMARY KEY, + episode_id UUID, + timestamp TIMESTAMPTZ, + source_agent_id UUID, + protocol_id UUID, + raw_message TEXT, + parsed_ast JSONB, + italian_render TEXT, -- per audit umano + parse_valid BOOLEAN +); + +-- Episodi (run di team) +CREATE TABLE episodes ( + id UUID PRIMARY KEY, + generation INT, + team_composition JSONB, -- {h: agent_id, f: agent_id, a: agent_id} + protocol_id UUID, + task_id UUID, + fitness FLOAT, + started_at TIMESTAMPTZ, + completed_at TIMESTAMPTZ +); + +-- Risultati discovery (per review umana) +CREATE TABLE discoveries ( + id UUID PRIMARY KEY, + episode_id UUID, + discovery_type TEXT, -- "alpha", "idiom", "attack_pattern" + content JSONB, + human_review_status TEXT, -- pending/valid/gaming/spurious + human_notes TEXT +); +``` + +### 6.3 Esempio di message bus auditato + +```python +class AuditedMessageBus: + async def send(self, source_agent: AgentGenome, + target_layer: Layer, + message: str, + protocol: ProtocolGenome) -> bool: + # 1. Parse with current protocol + try: + ast = protocol.parse(message) + except ParseError as e: + self.log_invalid(source_agent, message, e) + return False # silent drop + + # 2. Type check + if not protocol.type_check(ast): + self.log_invalid(source_agent, message, "type_error") + return False + + # 3. Italian rendering for audit + italian = protocol.render_italian(ast) + + # 4. Log + await self.log_message( + source=source_agent.id, + target=target_layer, + raw=message, + ast=ast, + italian=italian + ) + + # 5. Deliver + await self.deliver(target_layer, ast) + return True +``` + +--- + +## 7. Roadmap di Implementazione + +### 7.1 Fasi + +**Fase 0 — Validazione concettuale (1 mese)** +- Paper review approfondito (PromptBreeder, NEAT, MAP-Elites, emergent communication literature) +- Proof-of-concept minimo: 3 agenti hand-crafted (uno per layer), protocollo S-expr fisso, 10 ipotesi su dataset limitato +- Decisione go/no-go basata su: il sistema produce *qualcosa* di sensato? Vale espandere? + +**Fase 1 — Infrastruttura (2 mesi)** +- Message bus auditato (Python + Redis) +- Parser e validator del protocollo (Python, con grammar formale) +- Backtest engine deterministico (Rust + PyO3 bindings) +- Storage schema (PostgreSQL + pgvector) +- Multi-model router (Anthropic + OpenRouter) +- Logging, monitoring, dashboard base + +**Fase 2 — GA single-population (1 mese)** +- DEAP setup +- Evoluzione di solo Hypothesis layer (Falsification e Adversarial hand-crafted) +- Protocollo fisso +- Verifica anti-gaming sulla fitness function +- Calibrazione operatori genetici + +**Fase 3 — Multi-population co-evolution (2 mesi)** +- GA su tutte e tre le popolazioni di agenti +- Speciation, novelty search +- Protocol ancora fisso +- Task rotation per evitare overfitting + +**Fase 4 — Protocol evolution (2 mesi)** +- Aggiunta della quarta popolazione (protocollo) +- Idiom emergence detection +- Register specialization +- Sistema completo end-to-end + +**Fase 5 — Tuning e scaling (3-4 mesi)** +- Esperimenti su task diversi (trading, offerte commerciali, code review) +- Ablation studies (tier multi-model davvero aiuta? Quanto?) +- Long-run stability analysis +- Documentazione e potenziale paper + +**Totale realistico**: 11-12 mesi a impegno significativo (3-4 giorni/settimana). 18+ mesi a impegno part-time leggero. + +### 7.2 Tre opzioni decisionali + +**Opzione A — Big bet**: progetto principale per 12-18 mesi. Risultato: sistema completo, possibile paper, applicabile a multipli domini. Rischio: opportunity cost alto rispetto a Tielogic e altri progetti. + +**Opzione B — Smart spike**: solo Fasi 0-2 in 3-4 mesi. Output: infrastruttura solida + GA single-population funzionante su Hypothesis. Da lì si decide se espandere. Rischio basso, valore concreto. + +**Opzione C — Research dive**: solo Fase 0 in 1 mese. Decisione informata se vale la pena tutto. Rischio minimo, output principalmente conoscenza. + +--- + +## 8. Stima Costi (con tier multi-model) + +### 8.1 Costi LLM per fase + +| Fase | Generazioni | Pop totale | Costo stimato | +|------|-------------|------------|---------------| +| Fase 0 (PoC) | 0 (no GA) | 3 hand-crafted | $50-100 | +| Fase 2 | 50 | 100 | $400-700 | +| Fase 3 | 200 | 200 | $3-5K | +| Fase 4-5 | 500-1000 | 300-500 | $10-18K | + +**Totale fasi 1-5**: **$15-25K** in costi LLM (vs $30-50K senza tier multi-model). + +### 8.2 Altri costi + +- **Compute (server backtest, storage)**: $200-500/mese durante run attivi +- **Storage (TB di logs)**: $50-100/mese a regime +- **Tooling/infra setup**: ~$500 una tantum + +### 8.3 Costi nascosti + +- **Tempo umano**: la voce più importante. Calibrare fitness, fare review, debuggare gaming = molte ore/settimana durante run attivi +- **Iterazioni**: il primo run completo non funzionerà. Pianificare 2-3 run completi come parte del budget +- **Modelli che cambiano**: durante il progetto i prezzi e le capacità dei modelli evolveranno. Il tier multi-model può solo migliorare nel tempo + +--- + +## 9. Domini di Applicazione + +### 9.1 Trading derivati crypto (primario) + +- Task: identificare anomalie su Deribit options + Hyperliquid perps +- Fitness team: PnL OOS su walk-forward, Sharpe deflated, drawdown control +- Vantaggio: ground truth oggettivo (PnL), dataset abbondante, regime variations naturali +- Rischio: overfitting al regime di mercato durante training + +### 9.2 Offerte commerciali Tielogic (secondario) + +- Task: generare offerte tipo OFF-2026-XXX a partire da requisiti cliente +- Fitness team: qualità tecnica + commerciale + adesione template + tasso di conversione (firma cliente) +- Vantaggio: dataset di offerte passate (20-30) come ground truth implicito +- ROI immediato: ridurre tempo di stesura primi-draft significativamente +- Vincolo: dataset piccolo, attenzione a overfitting + +### 9.3 Code review e documentazione (terziario) + +- Task: generare review utili su PR, generare documentazione Swagger di qualità +- Fitness: bug catch rate su PR storiche, copertura/qualità docs +- Vantaggio: integrabile nel workflow Claude Code esistente +- Estensibilità: dopo trading, è il dominio più scalabile + +### 9.4 Generalizzabilità del protocollo + +Domanda di ricerca aperta: il protocollo evoluto su trading **trasferisce** ad altri domini, o ogni dominio sviluppa il suo dialetto? + +Ipotesi: la struttura generale (PROPOSE/CHALLENGE/REFINE/COMMIT) trasferisce, il vocabolario specifico no. Un'analisi sistematica di questo è materiale da paper. + +--- + +## 10. Risk Register + +| Rischio | Probabilità | Impatto | Mitigazione | +|-----------------------------|-------------|---------|----------------------------------------------| +| Fitness gameabile | Alta | Critico | Multi-livello fitness, human-in-the-loop, audit | +| Costi over-budget | Media | Alto | Tier multi-model, monitoring real-time, kill switch | +| Convergenza prematura | Media | Alto | Speciation, novelty search, immigrazione | +| Communication degeneration | Alta | Alto | Penalty leggibilità, parser strict, audit umano | +| Time over-budget | Alta | Medio | Opzione B/C come fallback | +| Modelli base cambiano | Certa | Medio | Re-evolution periodica, model_tier come gene | +| Backtest engine bug exploit | Media | Critico | Adversarial test del backtest, code audit | +| Burnout su side project | Alta | Critico | Roadmap realistica, milestone settimanali | + +--- + +## 11. Open Questions + +1. **Quanto è veramente diverso il sistema dal lavoro accademico esistente?** Necessario lit review serio prima di Fase 1. +2. **Il protocollo evoluto generalizza tra domini?** Domanda empirica, pubblicabile. +3. **Tier multi-model produce diversità cognitiva utile o solo riduce costi?** Ablation study cruciale. +4. **Co-evoluzione 4-popolazioni è stabile o tende a oscillare?** Non scontato, esperienza empirica necessaria. +5. **Quanto del successo dipende dal task specifico (trading) vs essere generale?** Solo applicazione multi-dominio risponde. +6. **Quanto è il vero MVP minimo per validare il concetto?** Probabilmente Fase 0 + minima Fase 2 con singola popolazione. + +--- + +## 12. Decisione Richiesta + +A questo punto del design, le decisioni concrete da prendere prima di partire: + +1. **Opzione A, B, o C?** — determina l'investimento di tempo +2. **Dominio iniziale: trading o offerte commerciali?** — trading ha dataset migliore, offerte ROI più rapido +3. **Hardware locale vs cloud?** — i backtest pesanti richiedono compute, decidere infrastructure +4. **Budget LLM iniziale committed?** — anche solo Fase 0 richiede $50-100 spendibile senza ansia +5. **Cadenza di review umana sostenibile?** — ore/settimana realisticamente disponibili + +--- + +## Appendice A — Bibliografia di riferimento + +**Da leggere prima di Fase 1**: +- PromptBreeder (DeepMind 2023): meta-evolution di prompt +- NEAT (Stanley & Miikkulainen 2002): speciation in neural evolution +- MAP-Elites (Mouret & Clune 2015): quality-diversity +- Novelty Search (Lehman & Stanley 2011): esplorazione vs sfruttamento +- DSPy (Khattab et al. 2023): ottimizzazione modulare di prompt +- TextGrad (Stanford 2024): backpropagation testuale +- Emergent Communication in Cooperative Multi-Agent RL (Foerster et al., Lazaridou et al. 2016-2020) +- Deflated Sharpe Ratio (Bailey & López de Prado 2014): per fitness trading +- Multiple testing in finance literature (López de Prado various) + +**Da consultare durante**: +- Anthropic prompt engineering documentation (per pattern caching) +- OpenRouter API docs (per multi-model routing) +- DEAP documentation (framework GA Python) +- Ray documentation (parallelizzazione) + +--- + +*Documento da aggiornare iterativamente. Questa è v0.1, scritta prima di qualunque implementazione.* diff --git a/docs/superpowers/specs/2026-05-09-decisione-strategica-design.md b/docs/superpowers/specs/2026-05-09-decisione-strategica-design.md new file mode 100644 index 0000000..77df3dd --- /dev/null +++ b/docs/superpowers/specs/2026-05-09-decisione-strategica-design.md @@ -0,0 +1,427 @@ +# Decisione Strategica PoC Multi-Swarm Coevolutivo — Design + +**Autore**: Adriano Dal Pastro +**Data**: 9 maggio 2026 +**Status**: Design strategico approvato per implementazione +**Versione**: 1.0 +**Documenti correlati**: +- `00_documento_zero.md` (framework concettuale) +- `coevolutive_swarm_system.md` (Filone A, sistema completo) +- `poc_trading_swarm.md` (Filone B, design PoC trading) + +--- + +## 1. Executive Summary + +Questo documento formalizza la decisione strategica su come avviare il progetto Multi-Swarm Coevolutivo. La scelta cade sulla variante **B3 — PoC trading incrementale a tre fasi con gate go/no-go**, una declinazione disciplinata dell'opzione Smart Spike (Filone B) descritta nel documento zero. + +La forma incrementale tripartita non sostituisce il design del PoC contenuto in `poc_trading_swarm.md`, ne organizza l'esecuzione in fasi successive con kill-switch numerici espliciti. Il principio guida è **applicare al progetto stesso la disciplina che il sistema dovrà applicare alle proprie ipotesi**: spegnere ciò che non funziona quando i dati lo dicono, senza sconti emotivi e senza giudizi soggettivi sui hard gate. + +**Vincoli operativi adottati**: + +| Dimensione | Valore | +|---|---| +| Obiettivo primario | Sistema produttivo che generi valore (trading reale, fase posteriore al PoC) | +| Dominio iniziale | Derivati crypto BTC/ETH | +| Tempo committed | Full-time, oltre 30h settimanali | +| Budget LLM cap | $2.200 hard, segmentato per fase | +| Capitale a rischio | $500-2.000 (solo nella Phase 3 forward-test mainnet) | +| Tempo calendario | 14-18 settimane atteso, 20 settimane hard cap | +| Setup tecnico di partenza | Cerbero_mcp operativo (multi-exchange, indicatori, audit, dual env) | + +**Esito atteso**: alla fine delle tre fasi, una decisione binaria documentata con razionale numerico fra (a) avviare il sistema completo Filone A con confidence empirica forte, (b) iterare la Phase 2 su debolezze identificate, (c) pivotare su un dominio diverso (offerte commerciali Tielogic, code review), oppure (d) chiudere il progetto con learnings registrati. + +--- + +## 2. Razionale della scelta strategica + +### 2.1 Le tre opzioni del documento zero, oggi + +Il documento zero presenta tre opzioni: A (Big Bet, sistema completo, 12-18 mesi), B (Smart Spike, PoC trading, 3-4 mesi), C (Research Dive, paper review più PoC minimo, 1-2 mesi). Alla luce dei vincoli operativi sopra elencati, la valutazione cambia rispetto al momento in cui il documento zero è stato scritto. + +L'opzione A è esclusa dal vincolo budget. Le stime conservative del Filone A indicano costi LLM nell'ordine di $10.000-30.000 anche solo per la fase iniziale, contro un cap committed di $2.200. Non è una questione di tempo: il tempo full-time c'è. È che il rapporto fra costo del run e disponibilità non lo rende sostenibile senza una validazione empirica preliminare. + +L'opzione C sotto-utilizza due asset materiali. Il primo è la disponibilità full-time, che rende il vincolo "non posso permettermi di costruire infrastruttura" non applicabile. Il secondo è Cerbero_mcp, già operativo: leggere paper per due settimane senza scrivere codice produttivo significherebbe lasciare ferma un'infrastruttura già pronta a essere wrappata come tool layer per agenti LLM. + +Resta l'opzione B. Il documento zero la indicava come scelta preferita; questo documento la conferma e la struttura. + +### 2.2 Perché B3 e non B1 o B2 + +Tre varianti di B sono state considerate. + +La variante **B1 (Lean / single-shot)** comprime il PoC in un'unica run con popolazione ridotta a 20-30 agenti e tier C unico. Coerente con il budget tight, ma rischiosa: la dimensione della popolazione è il principale moltiplicatore di diversità nel sistema, e una popolazione undersized rischia di produrre un falso negativo. Si decreterebbe il sistema "non funzionante" quando in realtà non gli abbiamo dato il numero di tentativi necessari. + +La variante **B2 (Canonical / come da documento)** segue fedelmente `poc_trading_swarm.md` con K=50, mix tier B/C, full set di ablation. Tecnicamente solida ma sfora il budget cap di un fattore 1.5-2x. Adottabile solo accettando di alzare il cap a $3-4K, decisione non giustificabile senza segnali empirici preliminari. + +La variante **B3 (Incrementale)**, scelta, articola il PoC in tre fasi sequenziali con cap budget per fase e gate decisionali quantitativi fra una fase e la successiva. Phase 1 valida il loop tecnico con popolazione minima e tier economico. Phase 2 esegue il PoC canonico solo se Phase 1 passa. Phase 3 forward-testa con capitale reale solo se Phase 2 passa. Il budget totale resta entro $2.2K e il rischio di falso negativo viene ridotto dal fatto che la popolazione completa di Phase 2 non viene mai tagliata: viene messa al lavoro solo dopo che il loop è stato validato. + +La struttura tripartita ha anche un beneficio non monetario: i deliverable di Phase 1 e Phase 2 valgono anche se le fasi successive falliscono. Il backtest engine, il GA harness, la Cerbero integration, la dashboard Streamlit, la pipeline DSR sono tutti riusabili in caso di pivot di dominio. Solo il capitale di Phase 3 è genuinamente "a rischio" come costo della validazione. + +### 2.3 Coerenza con la filosofia del progetto + +Il documento zero al §3.3 identifica come takeaway fondamentale di Renaissance la disciplina di spegnere strategie quando l'edge svanisce, senza decisioni emotive. Il design B3 applica questa disciplina al progetto stesso, prima ancora che al sistema. I gate sono numerici, le soglie sono fissate prima di vedere i dati, l'azione di stop è meccanica quando un hard gate fallisce. Non c'è spazio per "magari un'altra generazione" o "i risultati erano quasi ottimi": la decisione è già scritta nel design. + +--- + +## 3. Vincoli di terminazione globali + +Tre kill-switch globali sopra le singole fasi: + +1. **Cap budget LLM globale**: $2.200 hard. Spesa effettiva monitorata da pagina Overview della dashboard, contatore aggiornato dopo ogni batch. Sforamento previsto entro la fase corrente → riformulazione scope, non incremento cap. +2. **Cap tempo calendario**: 14-18 settimane attese, **20 settimane hard cap** dalla settimana 1 della Phase 1 alla decisione formale post-Phase 3. Sforamento previsto del cap → decisione anticipata sulla base dei dati raccolti, non estensione del cap. +3. **Hard gate falliti**: per costruzione, un hard gate fallito chiude la fase corrente e non apre quella successiva. La decisione fra stop, pivot, o iterazione è formalizzata nel decision memo della fase chiusa, non nel passaggio automatico alla successiva. + +--- + +## 4. Phase 1 — Lean Spike + +**Obiettivo**: dimostrare che il loop tecnico funziona end-to-end. Non si misura ancora alpha: si misura se il sistema gira come progettato, se l'output LLM è formalizzabile, se la GA converge, se i costi sono prevedibili. + +### 4.1 Scope IN + +- Infrastruttura backtest minima: dataset 2 anni (2024-2026) di OHLCV 1h BTC/ETH, engine event-driven semplificato (no microstructure, no slippage modelling complesso, fees fissi a 5 basis points), walk-forward expanding 70/30. +- Wrapper Cerbero come tool layer per agenti: i tool MCP esistenti (`indicators`, `vol_cone`, `oi_weighted_skew`, indicatori options/microstructure/stats) tradotti in funzioni callable dagli agenti. Niente reimplementazione, solo wrapping. +- Protocollo S-expression fisso: 12-15 verbi disegnati manualmente come da `poc_trading_swarm.md` §2.2. Nessuna evoluzione del protocollo in questa fase. +- Hypothesis Swarm con K=20 agenti, tier C unico (Qwen 2.5 72B via OpenRouter). Mutazione e crossover prompt come da documento PoC. Nessuna speciation, nessun novelty bonus. +- Falsification e Adversarial layer hand-crafted, un agente fisso per ognuno, prompt manuali. Tier B (Sonnet 4.6) chiamato solo per i top-5 candidati a fine generazione, per contenere costi. +- Fitness function v0: DSR in-sample con drawdown penalty. No multi-livello, no out-of-sample ancora. +- GA loop: 8-12 generazioni, tournament selection, elitism k=2. + +### 4.2 Scope OUT (esplicito) + +- Multi-tier ablation comparativa. +- Out-of-sample DSR e hold-out finale. +- Random Forest baseline. +- Speciation, novelty, diversity metrics. +- Forward-test con capitale reale. +- Domini diversi da BTC/ETH. + +### 4.3 Budget e tempo + +- LLM: $500-700. Stima base: 20 agenti × ~8.000 token output medi × 10 generazioni × pricing Qwen ≈ $300, più 50% di overhead per Adversarial, Falsification e iterazioni di sviluppo, totale stimato $500-700. +- Tempo: 4-6 settimane full-time. Settimane 1-2 backtest engine e Cerbero wrapper, settimana 3 GA infrastructure e parser S-expression, settimane 4-5 tuning e run completo, settimana 6 analisi e decisione gate. +- Capitale a rischio: zero. + +### 4.4 Gate go/no-go (tutti AND) + +Cinque hard gate: + +1. **Loop converge**: la fitness mediana della popolazione cresce per almeno tre generazioni consecutive prima di plateau. +2. **Output formalizzabile**: almeno l'80% delle proposte LLM passano il parser S-expression senza intervento manuale. +3. **Tail superiore esiste**: i top-5 genomi hanno DSR in-sample pari ad almeno 1.5x la mediana di popolazione, segnale che esiste struttura e non solo rumore. +4. **Diversità non collassa**: entropia della distribuzione di fitness in popolazione superiore a 0.5 a fine run, evita la convergenza monocoltura. +5. **Cost predictability**: spesa effettiva entro ±30% della stima preventivata. + +Anche un solo hard gate fallito chiude la Phase 1. Decisione successiva (pivot, ridiscussione design, stop) presa nel decision memo, non automaticamente in Phase 2. + +### 4.5 Deliverable Phase 1 + +- Codice testato (pytest): backtest engine, Cerbero wrapper, GA loop, protocol parser. +- Report tecnico (~5 pagine): loop convergence con grafici, ispezione qualitativa dei top-5 genomi, parser failure modes osservati, costi reali vs preventivo, diversity metrics. +- Decision memo: vai/non-vai a Phase 2 con eventuali aggiustamenti di scope. + +--- + +## 5. Phase 2 — Canonical PoC + +**Obiettivo**: rispondere ai cinque test del PoC originale (`poc_trading_swarm.md` §1) con popolazione e infrastruttura adeguate. Solo questa fase produce una vera misura dell'edge potenziale del sistema. + +### 5.1 Scope IN (in aggiunta a Phase 1) + +- Hypothesis Swarm K=40, scaling della popolazione a un livello canonico ridotto (K=50 documento → K=40 per disciplina budget). +- Tier mix B/C: circa 70% Qwen/DeepSeek (tier C), 30% Sonnet 4.6 (tier B). L'ablation comparativa misura il valore aggiunto del tier B. +- Speciation di base: clustering dei genomi per cosine similarity dei prompt più cognitive_style. Si mantengono almeno 3 specie attive, ognuna con quote di tournament protette. +- Novelty bonus: fitness composta α·DSR_OOS + β·novelty_score, dove la novelty è calcolata come distanza behavioural dei segnali rispetto a un archivio di elite. +- Walk-forward expanding più hold-out finale: training Q1-2024 a Q4-2025 in walk-forward, hold-out intoccabile Q1-Q2 2026. +- Random Forest baseline: feature engineering classico (returns multi-orizzonte, RSI/MACD/ATR, vol cone, funding rate, OI changes), classificazione long/flat/short su orizzonti 1d e 4h, valutato sulla stessa hold-out. +- Adversarial layer hand-crafted potenziato: cinque prompt distinti (data snooping, lookahead, regime fragility, crowding, transaction cost erosion) eseguiti sui top-10 candidati prima della valutazione OOS. +- Falsification con Deflated Sharpe Ratio (Bailey & López de Prado), correzione Bonferroni sul numero totale di ipotesi testate. +- Fitness multi-livello: per-agent (contributo DSR), per-team (DSR portfolio), diversity penalty per ridurre collusione. + +### 5.2 Scope OUT + +- Co-evolution del protocollo (Filone A). +- Forward-test con capitale reale (Phase 3). +- Speciation NEAT-style completa. +- Idiom emergence. +- Domini diversi da trading. + +### 5.3 Budget e tempo + +- LLM: $700-1.100. Dettaglio stimato: tier C ~$500, tier B ~$400, overhead per ablation iterativa ~$200. Range ampio per consentire più cicli di ablation se i primi risultati lo richiedono. +- Tempo: 4-6 settimane full-time. Settimana 1 porting K=40, speciation, novelty. Settimane 2-3 ablation runs (tier C only, tier B only, mix; con e senza speciation). Settimana 4 hold-out evaluation, RF baseline, Adversarial sweep. Settimane 5-6 analisi statistica, report, decisione gate. +- Capitale a rischio: zero. + +### 5.4 Gate go/no-go + +**Hard gate (tutti AND, altrimenti stop)**: + +1. **Significatività statistica**: top genoma su hold-out con DSR > 1.0 e p-value < 0.05 dopo correzione Bonferroni. +2. **Sopravvivenza regime change**: DSR hold-out almeno 0.5x del DSR walk-forward — limite contro overfitting catastrofico. +3. **Batte baseline**: top-3 genomi con Sharpe OOS superiore al Sharpe RF baseline OOS, effect size non trascurabile (Cohen's d > 0.3 sul rolling Sharpe). + +**Soft gate (informano, non killano)**: + +4. **Diversità**: almeno 3 specie distinte sopravvivono a fine run, top-3 genomi non identici per signal correlation (ρ < 0.7). +5. **Tier B aggiunge valore**: l'ablation mostra Δ Sharpe OOS misurabile per tier mix vs tier C only. In caso negativo, Phase 3 può girare tier C only e il decision memo ne prende nota. + +Hard gate passati → Phase 3. Hard gate falliti → stop o pivot. Soft gate falliti → Phase 3 con scope ridotto e annotazioni nel report. + +### 5.5 Deliverable Phase 2 + +- Codice testato: speciation, novelty, ablation harness, RF baseline, DSR pipeline, Adversarial battery. +- Report scientifico (~15-20 pagine): metodologia, risultati per ogni gate, ablation table, top-5 strategie ispezionate qualitativamente, threats to validity. +- Decision memo: vai/non-vai a Phase 3, scope di Phase 3 (capitale, exchange, leva, durata) calibrato sui risultati. + +--- + +## 6. Phase 3 — Forward-test mainnet + +**Obiettivo**: vedere se l'edge sopravvive in produzione. Anche il backtest più rigoroso ha bias inevitabili (look-ahead microscopico, slippage idealizzato, assenza di information leakage da fonti che non esistevano in periodo storico). Solo il forward-test live risponde alla domanda finale. + +### 6.1 Scope IN + +- Selezione strategie: top-3 genomi out-of-sample dalla Phase 2, dopo passaggio completo dell'Adversarial battery. Niente cherry-picking ex-post post-Phase 2. +- Capitale: $500-2.000 totali, distribuiti sui tre genomi con allocazione equal weight oppure risk-parity sulla volatilità OOS attesa, scelta motivata nel decision memo Phase 2. +- Exchange: scelta condizionata alle strategie selezionate. Default raccomandati Bybit (perp, fees competitive, liquidità BTC/ETH adeguata) oppure Hyperliquid (no KYC, transparent funding). Cerbero supporta entrambi nativamente. +- Leva: massimo 2x in forward-test. Anche se lo Sharpe OOS suggerisse di più, in fase di validazione la leva resta bassa per non confondere edge della strategia con leva. +- Durata: 6-8 settimane continue. Razionale: in crypto questa finestra copre tipicamente uno o due micro-regime change, sufficienti a stressare il modello senza catastrofi statistiche da campione troppo piccolo. +- Monitoring: dashboard giornaliera (sezione Live Monitor) con Sharpe live realized vs Sharpe OOS atteso, drawdown realtime, violation count (segnali generati ma non eseguiti per qualunque ragione), audit log Cerbero per ogni order. +- Decision triggers automatici: kill-switch se il drawdown live supera 1.5x il peggiore osservato in walk-forward; pause se Sharpe rolling 14d resta negativo per 14 giorni consecutivi. +- Adversarial post-mortem settimanale: l'agente Adversarial gira nuovamente sul signal log della settimana per identificare degradazione dell'edge (regime drift detection). + +### 6.2 Scope OUT + +- Capital scaling oltre $2.000 in Phase 3. Se i risultati promettono, la decisione di scaling è esplicitamente fuori dal PoC e viene presa dopo il decision memo finale. +- Multi-strategy portfolio rebalancing dinamico. Allocazione statica sui tre genomi. +- Hedging cross-exchange. Confonderebbe la lettura dell'edge della strategia. +- Aggiunta di nuovi genomi in corsa. I tre genomi sono fissati a inizio fase. + +### 6.3 Budget e tempo + +- LLM: $200-400. La popolazione GA non gira più, gli agenti sono richiamati solo per Adversarial post-mortem settimanale e per occasionali refresh quando i decision triggers scattano. +- Capitale a rischio: $500-2.000. Trattato come **costo della validazione**, non come investimento. Se il capitale va a zero, il dato che ne ricaviamo vale comunque. +- Tempo: 6-8 settimane di calendario, monitoring operativo circa 5h/settimana — non full-time. Le settimane libere sono allocate a documentazione finale, lavoro su Tielogic e altri progetti, prima esplorazione Filone A in caso di decisione GO. +- Costo infra extra: circa $10-30/mese VPS per dashboard più monitoring, in larga parte già coperto dal setup Hostinger esistente. + +### 6.4 Gate decisionale finale del PoC + +**Hard gate per "GO sistema completo / Filone A"**: + +1. **Edge sopravvive live**: Sharpe live realized almeno 0.5x dello Sharpe OOS atteso, su finestra di almeno 4 settimane. +2. **No catastrophic failure**: max drawdown live al massimo 1.5x del peggior drawdown walk-forward. +3. **Reproducibility**: almeno 2 dei 3 genomi performano in linea con previsione — la fortuna non si concentra su uno solo. + +**Soft gate (qualitativi, informano la decisione)**: + +4. **Audit Adversarial settimanali**: nessuna scoperta critica come lookahead nascosto emerso solo live, oppure data leakage da provider. +5. **Cost economy**: edge dopo costi reali (slippage effettivo, fees, funding) resta positivo. + +**Esiti possibili**: + +- Hard gate e soft gate tutti passati → GO Filone A con confidence empirica forte. Si apre la ridiscussione del budget e della roadmap del sistema completo, fuori dal perimetro di questo documento. +- Hard gate passati, soft gate falliti → iterazione Phase 2 mirata sulle debolezze identificate, no Filone A immediato. +- Hard gate falliti, ma senza catastrofi → l'idea regge concettualmente ma non scala live retail. Decision memo con due opzioni: pivot dominio (offerte Tielogic, code review) oppure chiusura del progetto. +- Hard gate falliti più drawdown catastrofico → l'idea non regge live. Stop del progetto. Documento di chiusura con learnings registrati per progetti futuri. + +### 6.5 Deliverable Phase 3 e finali + +- Report finale del PoC (~20-30 pagine): metodologia completa, risultati Phase 1+2+3, comparison Sharpe in-sample / OOS / live, ispezione qualitativa delle strategie, learnings, threats to validity confermati o respinti. +- Decision memo strategico: GO Filone A / iterate Phase 2 / pivot dominio / stop, con razionale quantitativo ancorato ai gate. +- Codebase pubblicabile (anche se repo privato): backtest, GA, Cerbero integration, speciation, DSR pipeline, RF baseline, monitoring dashboard, tutto documentato. + +--- + +## 7. GUI Streamlit incrementale + +Una dashboard è essenziale per ispezionare cosa fa il sistema, decidere i gate in modo informato, e produrre i grafici che entreranno nei report. + +### 7.1 Architettura + +- Tech stack: Streamlit single-app multi-page, dati letti da SQLite locale (`runs.db`) e Parquet per series numerici pesanti. +- SQLite per stato: genomi, generazioni, fitness, ablation results, adversarial findings, trade log. Schema relazionale stabile, query veloci, nessun DB server da gestire. +- Parquet per series: equity curves, signal time series, OHLCV. File-based, columnar, leggero. +- Auto-refresh ogni 10 secondi nella sola pagina Live Monitor (Phase 3). Sufficiente per uno scope a decisioni minute-level, non HFT. +- Single app, multipage: tutto sotto `dashboard/streamlit_app.py` più `pages/`. Deploy locale con `streamlit run`, niente VPS frontend. + +### 7.2 Pagine costruite incrementalmente + +**Phase 1 (3-4 giorni di lavoro)**: + +- *Overview*: ultima run, generazione corrente, stato (running/completed/failed), spesa LLM cumulata vs cap. +- *GA Convergence*: line plot fitness mediana / max / 90° percentile per generazione, distribuzione fitness ultima generazione (histogram), counter chiamate LLM e costo. +- *Genomes (basic)*: tabella top-10 genomi correnti con DSR, cognitive_style, temperature, lookback. Click su riga apre side panel con system_prompt completo, feature_access, lineage parent_id. + +**Phase 2 (9-12 giorni distribuiti)**: + +- *Genomes (avanzato)*: lineage tree interattivo (parent → children su 15 generazioni), speciation cluster view (UMAP/t-SNE su prompt embedding più parametri, colori per specie), filtri per specie / tier / cognitive_style. +- *Performance*: equity curve in-sample, walk-forward, OOS, hold-out per ogni genoma. Sharpe, DSR, drawdown. Trade distribution per regime di volatilità, asset, orario. Per-strategy e portfolio view. +- *Ablation*: confronto runs (tier C only, tier B only, mix) side-by-side. Δ Sharpe OOS, costo per percentile fitness, breakeven analysis. +- *Adversarial*: per ogni top-10 genoma, le cinque critiche (data snooping, lookahead, regime fragility, crowding, transaction cost). Click espande prompt completo, risposta LLM, decisione pass/fail con rationale. +- *RF Baseline*: Sharpe RF baseline OOS, feature importance, comparison vs top-3 swarm, Cohen's d effect size. + +**Phase 3 (4-5 giorni)**: + +- *Live Monitor*: P&L realtime per strategia e portfolio, equity curve da inizio Phase 3, drawdown rolling. Auto-refresh 10s. +- *Live vs OOS*: Sharpe live realized vs Sharpe OOS atteso (con confidence interval), gauge "edge sopravvive?", cumulative deviation tracker. +- *Triggers state*: stato kill-switch per strategia, distance from threshold, history pause/resume, audit log decisioni recenti. +- *Adversarial weekly*: report settimanale di regime drift detection, diff vs settimana precedente. + +### 7.3 Costi GUI + +- Effort totale: 16-21 giorni netti, distribuiti come da fasi sopra. +- LLM: zero (codice e visualizzazione Python locale). +- Infra: zero (esecuzione locale, SQLite locale, Parquet locale). + +### 7.4 Trade-off accettati + +- Refresh non realtime sub-secondo: accettabile per scope decisionale minute/hour. +- Niente login né multi-utente: dashboard personale solo locale. +- Niente alert push esterni in default: alert appaiono in dashboard. Per Phase 3 si può aggiungere webhook Telegram/email se necessario, mezza giornata extra di lavoro. +- Streamlit re-runs full-page on interaction: gestibile con `@st.cache_data` su query SQLite e dataset PoC di dimensioni contenute. + +### 7.5 Deliverable GUI + +- Codice `dashboard/` testato (smoke test e data layer test). +- Schema SQLite versionato con migrazioni semplici (Alembic light o script SQL). +- README con istruzioni `streamlit run` e descrizione di ogni pagina. + +--- + +## 8. Hardware e infrastruttura + +Principio: tutto locale più Cerbero come unico servizio remoto. Nessuna GPU, nessun cloud compute, nessun costo infra ricorrente significativo. + +### 8.1 Compute + +- Backtest e GA loop: PC locale Linux. Tutto CPU-bound, parallelizzabile su core (joblib o multiprocessing). Dataset 2 anni OHLCV 1h BTC+ETH circa 30-50 MB. Anche granularità 1m sarebbe sotto i 2 GB, gestibile. +- LLM: tutte chiamate via API esterne (OpenRouter per tier C, Anthropic per tier B). Nessun model locale, nessuna GPU. +- Streamlit dashboard: locale (`streamlit run` su `localhost:8501`). + +### 8.2 Cerbero_mcp + +Già configurato e operativo. Modalità d'uso durante PoC: + +- Locale via Docker compose durante development e Phase 1-2 (testnet only). Riduce latenza, niente costi VPS, debug più rapido. +- VPS Hostinger durante Phase 3 forward-test (mainnet). Già setup `/opt/cerbero-mcp` con `deploy-vps.sh` e branch V2.0.0. +- Token bearer: `TESTNET_TOKEN` per Phase 1-2 backtest replay, `MAINNET_TOKEN` solo per Phase 3. +- Bot tag dedicato per il PoC (`X-Bot-Tag: swarm-poc-`). L'audit log Cerbero traccia ogni call separatamente per fase, utile per ricostruzioni post-mortem. + +### 8.3 Storage + +- `runs.db` SQLite per stato GA, genomi, generazioni, fitness, adversarial, trade log. Backup giornaliero su disco esterno o cloud personale. +- `series/` Parquet per equity curves, signal time series, OHLCV cache. Versionato fuori da git (Git LFS o cartella esterna trackata in `.gitignore`). +- Audit log Cerbero: già JSONL con rotazione 30 giorni (`AUDIT_LOG_BACKUP_DAYS=30`). Per Phase 3 aumentare a 90 giorni per coprire intera fase più post-mortem. + +### 8.4 Networking + +- LLM API via OpenRouter (tier C) e Anthropic (tier B). Nessun setup speciale. +- Cerbero locale: porta 9000 default, nessuna esposizione pubblica. +- Cerbero VPS: già protetto da Traefik più bearer più allowlist IP. Nessun lavoro extra. + +### 8.5 Costi infra ricorrenti + +- VPS Hostinger: già pagato per altri progetti, costo marginale zero. +- Storage backup: trascurabile. +- Domini e TLS: già coperti (cerbero-mcp.tielogic.xyz). + +### 8.6 Decisioni hardware non bloccanti + +- Se la Phase 2 ablation richiedesse parallelizzazione massiva (ad esempio cento backtest concorrenti), valutare spot instance AWS o Hetzner. Probabilmente non necessario, le strategie a granularità 1h sono veloci da backtestare anche su CPU desktop. +- Backup off-site di `runs.db`: decisione di lifecycle, non bloccante per Phase 1. + +--- + +## 9. Cadenza review e disciplina autoriale + +Regola personale dell'autore: mai self-approve, separare author pass da review pass. Applicata sistematicamente ai gate del PoC. + +### 9.1 Cadenza working + +- Daily: lavoro full-time. Self-review informale a fine giornata, una riga nel commit message su cosa è andato e cosa no. +- Settimanale (venerdì): review formale con dump strutturato che include fitness convergence plot, top-5 genomi della settimana, spesa LLM accumulata vs cap di fase, eventuali findings Adversarial significativi, aggiornamento di `progress.md`. +- Bi-settimanale: snapshot completo più decision check sul fatto se siamo ancora on-track per il gate. Se due bi-weekly consecutivi mostrano off-track materiale, decisione anticipata di pivot o iterate, non attesa fino a fine fase. + +### 9.2 Gate review (decisione formale fine fase) + +Per ognuno dei tre gate (fine Phase 1, fine Phase 2, fine Phase 3): author pass e review pass separati. + +- **Author pass**: l'autore scrive il decision memo con tutti i numeri, gate per gate, conclusione raccomandata. +- **Review pass**: secondo passaggio con approccio adversarial. Tre opzioni equivalenti: + - Subagent Claude con prompt esplicitamente "red team" che riceve memo più dati grezzi e produce critica strutturata (cherry-picking, debolezze statistiche, omissioni). + - Collega umano disponibile, se esiste un contesto Tielogic adatto. + - Rilettura dopo 48 ore con timer, fresh eyes pass. +- **Sintesi**: solo dopo il review pass la decisione viene formalizzata e committata. + +### 9.3 Decision triggers oggettivi + +I gate hard di ogni fase sono numerici (DSR, p-value, drawdown ratio). La decisione GO/STOP è meccanica sui hard gate: + +- Hard gate fallito → STOP automatico, non in discussione. +- Hard gate passato → si valuta se i soft gate danno motivo di iterazione invece di procedere. + +Questa è la disciplina Renaissance applicata al progetto: niente "magari un'altra generazione" se il numero non lo dice. + +### 9.4 Documentazione del processo + +- `docs/runs/YYYY-MM-DD-phase{1,2,3}-run-N.md` per ogni run completato: configurazione, risultati, anomalie, learning. +- `docs/decisions/YYYY-MM-DD-gate-phase{1,2,3}.md` per ogni decisione gate: author pass, review pass, decisione finale, razionale. +- Questo documento (`docs/superpowers/specs/2026-05-09-decisione-strategica-design.md`) come north star strategico, aggiornato se cambiano vincoli o decisioni macro. + +--- + +## 10. Catena di ragionamento (tracciabilità) + +Per riferimento futuro, la sequenza logica che ha portato al design B3: + +1. Obiettivo dichiarato sistema produttivo che generi valore → esclude C (research dive senza output produttivo). +2. Dominio iniziale trading crypto → allinea il PoC al design già scritto in `poc_trading_swarm.md`. +3. Tempo full-time disponibile → scioglie il vincolo "non posso costruire infrastruttura", apre spazio per fasi sequenziali. +4. Budget LLM tight ($1-2K) → esclude A (Filone completo) e impone disciplina su B. +5. Setup Cerbero_mcp esistente → riduce settimane di plumbing, gli agenti chiamano tool MCP nativi. +6. Forward-test mainnet con capitale piccolo come parte del successo → richiede una Phase 3 dedicata, distinta dalla validazione statistica. +7. Disciplina "spegnere ciò che non funziona" → struttura tripartita con kill-switch numerici. +8. Mai self-approve → separazione author pass / review pass nei gate. +9. Necessità di ispezionare cosa fa il sistema → GUI Streamlit come componente orizzontale, non opzionale. + +--- + +## 11. Decisioni risolte e decisioni ancora aperte + +### 11.1 Risolte da questo documento + +- Opzione strategica: B3. +- Dominio iniziale: trading derivati crypto BTC/ETH. +- Numero di fasi: tre, con gate go/no-go fra una e l'altra. +- Budget cap globale: $2.200 LLM più $500-2.000 capitale a rischio Phase 3. +- Cap calendario: 18 settimane. +- Tier mix: solo C in Phase 1, mix B/C in Phase 2-3. +- Tech stack GUI: Streamlit più SQLite più Parquet. +- Infrastruttura: locale più Cerbero_mcp esistente. +- Cadenza review: settimanale, bi-settimanale per check, gate con author/review pass separati. + +### 11.2 Aperte (non bloccanti per Phase 1) + +- Allocazione capitale Phase 3 (equal weight vs risk-parity): decisione formalizzata nel decision memo Phase 2 sulla base dei risultati OOS. +- Exchange Phase 3 (Bybit vs Hyperliquid): scelta dipendente dalle strategie selezionate, decisa nel decision memo Phase 2. +- Approccio review pass (subagent vs umano vs fresh eyes): decisione tattica per gate, nessun lock-in. +- Webhook alert Telegram/email per Phase 3: opzionale, decidibile a inizio Phase 3. + +### 11.3 Esplicitamente fuori scope + +- Filone A (sistema completo) come fase corrente. Decisione su A presa solo dopo decision memo finale Phase 3. +- Filone C (applicazioni non-trading: offerte Tielogic, code review, doc Swagger). Possibile pivot in caso di hard gate falliti, non azione preventiva. +- Co-evolution del protocollo. Nessuna delle tre fasi PoC la include. +- Capital scaling oltre $2.000 in Phase 3. Decisione di scaling appartiene a una fase successiva al PoC. + +--- + +## 12. Prossimi passi + +Esecuzione di Phase 1. + +Il piano implementativo dettagliato di Phase 1 (settimana per settimana, task atomici, dipendenze, verifiche) sarà oggetto del documento successivo, da costruire con l'invocazione dello skill `writing-plans` su questo design. + +--- + +*Documento approvato il 9 maggio 2026. Versione 1.0. Aggiornare in caso di modifica dei vincoli operativi o di esiti di gate che richiedano revisione strategica complessiva.* diff --git a/poc_trading_swarm.md b/poc_trading_swarm.md new file mode 100644 index 0000000..cc4d204 --- /dev/null +++ b/poc_trading_swarm.md @@ -0,0 +1,831 @@ +# 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`*