Multi_Swarm_Coevolutive/coevolutive_swarm_system.md

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:

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

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

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

@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 := <type:value:metadata>

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:

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)

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

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.