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**:
```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 := <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**:
```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.*