Capitolo 13 - Benchmark, disegno sperimentale, replicabilità multi-dominio

Metadati:

• Versione: v1.0
• Data: 2026-04-22
• Stato: draft completo
• Autore: Fabio Ghioni
• Allineato a: TE_CORE v5.1 / OST v2.1 / OCT baseline v1.0 candidate
• Dipendenze: Capitolo 12 (protocollo PV-8), OCT_VALIDATION_PROTOCOL_v0_1, report Cycle 2-4
• Target parole capitolo: 2.800

1. Problema

Il Capitolo 12 ha definito la grammatica metodologica della validazione OCT. Ma un protocollo, da solo, non garantisce prova robusta: serve un disegno benchmark che produca evidenza comparabile nel tempo, nei team e nei domini.

Nel lavoro ordinativo il rischio principale e doppio:

1. benchmark troppo facili, che confermano qualsiasi ipotesi già favorita;
2. benchmark non comparabili, che impediscono di distinguere progresso reale da variazione accidentale.

Per questo il problema del capitolo e preciso:

come costruire un sistema benchmark multi-dominio che renda misurabile la differenza tra performance locale e validazione trasferibile, senza collassare la teoria in una pura ottimizzazione numerica?

1.1 Dal protocollo all'infrastruttura

Il protocollo (Capitolo 12) risponde a "come decidere". Il benchmark design risponde a "su cosa decidere". La tenuta scientifica richiede entrambi.

Senza infrastruttura benchmark:

1. i claim restano narrativi;
2. le repliche sono episodiche;
3. la decisione validated resta fragile.

Con infrastruttura benchmark:

1. i claim sono testati in condizioni comparabili;
2. le repliche indipendenti diventano obbligatorie, non opzionali;
3. la curva di evidenza può essere monitorata per versione.

1.2 Scope della milestone v1.4

Il Capitolo 13 ha funzione ponte tra metodo e governance:

1. implementa la PV-8 in benchmark reali;
2. definisce la nozione operativa di indipendenza benchmark;
3. prepara il Capitolo 14 su audit trail, gate e versioning epistemico.

2. Tesi del capitolo

La tesi e articolata in dieci enunciati.

1. Un claim OCT e robusto solo se supera benchmark indipendenti per costruzione, non solo per nome.
2. L'indipendenza benchmark richiede separazione di dati, seed policy, tuning e log namespace.
3. La replicabilità multi-dominio e criterio strutturale, non supplemento statistico.
4. Le metriche canoniche (Coh, Phi, Delta) devono convivere con metriche specifiche per task.
5. La stratificazione dei casi e necessaria per evitare conferme trainate da sottogruppi facili.
6. L'analisi di sensibilità e parte del test principale, non appendice facoltativa.
7. Il fallimento parziale e informazione scientifica e va pubblicato con stessa disciplina dei successi.
8. Ogni benchmark deve includere policy di replay e criteri di rerun tracciati.
9. Un pacchetto benchmark senza manifest e hash non e considerato riproducibile oltre livello R1.
10. Il disegno proposto e sufficiente per sostenere la governance epistemica del Capitolo 14.

3. Definizioni canoniche

Definizione 13.1 (Benchmark indipendente)

Due benchmark B_i, B_j sono indipendenti se valgono simultaneamente:

1. D_i ∩ D_j trascurabile rispetto a soglia preregistrata;
2. seed policy distinta;
3. assenza di tuning trasversale post-freeze;
4. log namespace separato e auditabile;
5. shift di distribuzione dichiarato e verificabile.

Definizione 13.2 (Asse di dominio)

Un asse di dominio A_k e una famiglia coerente di contesti osservativi Omega che condividono:

1. tipo di oggetti/morfismi osservati;
2. regime di rumore dominante;
3. criteri semantici di errore.

Esempi operativi per OCT:

1. A_struct: strutture compositive e diagrammatiche;
2. A_pipeline: processi multi-step di trasformazione;
3. A_social: dinamiche narrative longitudinali.

Definizione 13.3 (Pacchetto benchmark minimo)

PB_min := <Manifest, Dataset, Script, Config, Hash, Report, DecisionTable>.

Un benchmark e considerato pubblicabile solo se il pacchetto minimo e completo.

Definizione 13.4 (Replicabilità multi-dominio)

Un claim e multi-dominio replicabile se la conferma si osserva in almeno due assi A_k con contesti non equivalenti banalmente.

Definizione 13.5 (Stress strutturale)

Stress strutturale: perturbazione controllata che aumenta difficolta compositiva mantenendo il significato del claim.

Definizione 13.6 (Indice di trasferibilità)

Per claim C:

T_C := mean_k(score_k) - penalty_var

con:

1. score_k performance ordinativa su asse A_k;
2. penalty_var penalità per variabilità eccessiva cross-dominio.

T_C alto indica robustezza trasferibile; T_C basso indica risultato locale.

4. Sviluppo formale

4.1 Architettura benchmark in tre livelli

Proponiamo un'architettura a tre livelli.

1. Livello L1 (core test): verifica diretta del claim su benchmark principale.
2. Livello L2 (indipendenza): replica su benchmark #2 con shift esplicito.
3. Livello L3 (stress/audit): sensibilità a soglie, ablation, replay indipendente.

La regola e semplice:

1. L1 senza L2 produce solo evidenza preliminare;
2. L1+L2 senza L3 produce evidenza promettente ma incompleta;
3. L1+L2+L3 e condizione standard per decisione forte.

4.2 Disegno degli assi di dominio

Il framework OCT ha già evidenziato tre famiglie di test rilevanti:

1. D02 (commutatività non produttiva) su asse strutturale;
2. A01 (stabilità pipeline IA) su asse operativo-procedurale;
3. D03 (perdita ontologica forgetting) su asse misto strutturale-operativo.

Questa triade e utile perché copre:

1. differenza puramente compositiva;
2. utilità pratica su pipeline reali;
3. perdita di struttura sotto trasformazioni canoniche.

Il capitolo impone che ogni nuova campagna espliciti a priori quale asse copre e quale resta non coperto.

4.3 Criteri operativi di indipendenza

L'indipendenza non può essere dichiarata genericamente. Va verificata con checklist.

Checklist minima:

1. NO riuso campioni dal benchmark precedente oltre soglia consentita;
2. split dati congelato prima del run;
3. separazione delle seed rispetto al ciclo precedente;
4. divieto di tuning post-freeze;
5. motivazione obbligatoria per rerun con hash log.

Questi criteri sono coerenti con il manifest Cycle 3 e con la policy di execution lock già adottata.

4.4 Stratificazione campionaria e copertura

Ogni benchmark deve esplicitare stratificazione su tre assi:

1. complessità strutturale;
2. livello di rumore;
3. ambiguità contestuale.

Se uno strato e sottocampionato, il claim non può essere generalizzato. In pratica:

1. risultati aggregati senza breakdown di strato sono considerati incompleti;
2. la decisione può al massimo restare in revise.

4.5 Piano statistico minimo

Senza imporre un unico paradigma statistico, fissiamo cinque obblighi minimi:

1. ipotesi nulla/alternativa dichiarate;
2. soglia alpha preregistrata;
3. misura di effetto oltre al p-value;
4. intervalli di confidenza o stima di incertezza equivalente;
5. criterio di successo aggregato multi-contesto.

Il capitolo privilegia inferenza trasparente rispetto a ottimizzazione retorica di singole metriche.

4.6 Potenza e numerosità campionaria

La numerosità non può essere scelta solo per convenienza computazionale. Deve essere giustificata da:

1. variabilità attesa;
2. effetto minimo di interesse;
3. livello di confidenza richiesto per decisione.

Se la potenza e insufficiente, un esito "non significativo" non autorizza rigetto del claim; autorizza solo revisione del disegno.

4.7 Multi-contesto e regola 2/3

In continuità con i cicli già eseguiti, adottiamo una regola pragmatica:

1. conferma minima in almeno 2/3 contesti preregistrati;
2. il terzo contesto può fallire solo con analisi causale esplicita.

La regola evita due estremi:

1. rigidità eccessiva (richiedere successo perfetto in ogni micro-variante);
2. permissività eccessiva (accettare successo in un solo contesto favorevole).

4.8 Instrumentation e audit trail

La replicabilità dipende più dai log che dalle intenzioni. Ogni run deve produrre:

1. manifest versione dati e script;
2. checksum artefatti;
3. parametri runtime;
4. output metrici raw e aggregati;
5. decision trace leggibile.

Senza questa catena, il risultato resta al massimo R1 e non supporta validazione forte.

4.9 Tassonomia degli errori

Per evitare diagnosi vaghe introduciamo una tassonomia minima degli errori benchmark:

1. E_data: incoerenza o leakage nei dati;
2. E_model: instabilità del mapping o della pipeline;
3. E_metric: mismatch tra metrica e significato del claim;
4. E_context: trasferimento improprio tra domini;
5. E_decision: applicazione incoerente della matrice decisionale.

Ogni errore va classificato in severità (low, medium, high) e associato ad azione correttiva.

4.10 Policy di rerun e freezing

Il rerun e lecito solo se:

1. motivazione tecnica documentata;
2. stessa preregistrazione o nuova preregistrazione versionata;
3. dichiarazione esplicita di cosa cambia e cosa resta invariato.

Il freezing conclude una fase sperimentale e blocca la retro-modifica opportunistica dei criteri.

4.11 Disegno per pubblicazione aperta

Un benchmark scientificamente utile e anche pubblicabile in forma verificabile.

Pacchetto raccomandato:

1. repository operativo (GitHub) con script e manifest;
2. snapshot DOI (Zenodo) della release validata;
3. workspace progettuale (OSF) con preregistrazioni e materiale intermedio;
4. eventuale mirror dataset (Hugging Face) con dataset card metodologica.

La chiave non e moltiplicare piattaforme, ma preservare coerenza di versione tra piattaforme.

4.12 Condizione di sufficienza del capitolo

Il capitolo e metodologicamente sufficiente se produce tre risultati:

1. definizione operativa di benchmark indipendente;
2. schema di replicabilità multi-dominio con criteri espliciti;
3. pipeline pubblicabile e auditabile end-to-end.

Questa condizione e soddisfatta dalle definizioni 13.1-13.6 e dai blocchi 4.1-4.11.

4.13 Indice di qualità benchmark Q_B

Per confrontare campagne diverse introduciamo un indicatore sintetico:

Q_B := a*Ind + b*Rep + c*Trace + d*Stress - e*Leak

dove:

1. Ind misura l'indipendenza effettiva tra benchmark;
2. Rep misura il tasso di repliche riuscite;
3. Trace misura la completezza dell'audit trail;
4. Stress misura copertura e severità dei test di sensibilità;
5. Leak penalizza leakage dati e tuning opportunistico.

Vincoli operativi:

1. coefficienti a,b,c,d,e >= 0;
2. a+b+c+d+e = 1;
3. soglia minima preregistrata per rilascio esterno.

Q_B non sostituisce la decisione teorica sul claim, ma decide la prontezza metodologica del pacchetto benchmark.

4.14 Protocollo di replica indipendente

Per dichiarare una replica realmente indipendente proponiamo il seguente protocollo minimo:

1. team esecutore differente da quello del benchmark originario;
2. ambiente ricostruito da zero usando solo artefatti pubblici;
3. verifica hash di dataset/script prima del run;
4. esecuzione senza modifica dei criteri decisionali preregistrati;
5. report finale con confronto puntuale tra esito originario e replica.

La replica indipendente non e una formalità: e il passaggio che trasforma un risultato interno in conoscenza affidabile per la comunità.

5. Proposizioni e teoremi locali

Proposizione 13.1 (Insufficienza del benchmark nominalmente diverso)

Enunciato: Due benchmark con nomi differenti ma senza separazione di dati/seed/tuning non forniscono evidenza indipendente.

Intuizione: l'indipendenza e proprietà del processo, non dell'etichetta.

Stato: validated.

Proposizione 13.2 (Necessità della stratificazione)

Enunciato: Senza stratificazione esplicita, la performance aggregata può sovrastimare la robustezza di un claim.

Intuizione: la media può nascondere collassi locali ad alta rilevanza teorica.

Stato: validated.

Proposizione 13.3 (Valore informativo del fallimento)

Enunciato: Nel contesto OCT, un fallimento tracciato e classificato aumenta informazione metodologica più di un successo non auditabile.

Intuizione: il fallimento ben localizzato orienta revisione teorica e disegno successivo.

Stato: in_review.

Teorema 13.4 (Sufficienza operativa del disegno L1-L2-L3)

Ipotesi:

1. benchmark L1 con preregistrazione completa;
2. benchmark L2 indipendente secondo Def. 13.1;
3. stress/audit L3 con report riproducibile.

Tesi: Il claim testato dispone di evidenza metodologicamente sufficiente per decisione validated/revise/reject non arbitraria.

Proof sketch:

1. L1 fornisce test diretto del claim;
2. L2 limita overfitting al benchmark iniziale;
3. L3 misura robustezza a perturbazioni e integrità della catena di prova.

Conseguenze: fornisce standard minimo per promozione di stato in catalogo teorematico OCT.

Stato: in_proof.

Teorema 13.5 (Necessità della replicabilità multi-dominio)

Ipotesi:

1. claim confermato solo su un asse di dominio;
2. assenza di repliche su asse indipendente;
3. elevata variabilità potenziale tra contesti.

Tesi: La conferma mono-dominio non e sufficiente per inferenza generale in OCT.

Proof sketch:

1. la semantica ordinativa dipende da Omega;
2. cambi di dominio alterano distribuzioni e vincoli compositivi;
3. senza replica multi-asse non si distingue effetto teorico da compatibilità locale.

Conseguenze: legittima la regola di replicazione minima su assi multipli.

Stato: in_proof.

6. Implicazioni operative

6.1 Per il Capitolo 14 (governance epistemica)

Il capitolo consegna a v1.4 tre oggetti che il Capitolo 14 dovra governare:

1. versioni benchmark e relativi freeze;
2. audit trail dei rerun;
3. criteri di accettazione legati a livelli di riproducibilità.

6.2 Per il programma di validazione teoremi

La struttura L1-L2-L3 permette di ordinare i teoremi in priorità:

1. teoremi ad alto impatto con percorso completo immediato;
2. teoremi esplorativi con L1 rapido e ingresso in coda L2/L3;
3. teoremi in conflitto con focus su stress e ablation prima del rilascio.

6.3 Per pubblicazione e revisione esterna

Un revisore esterno deve poter rispondere a tre domande senza ambiguità:

1. che cosa e stato testato;
2. come e stato testato;
3. perché la decisione finale e giustificata.

Il capitolo offre una struttura che rende queste risposte ispezionabili.

6.4 Per roadmap 2026-2030

La replicabilità multi-dominio e il criterio che separa:

1. risultati locali da risultati fondativi;
2. prototipi interni da standard scientifici pubblicabili.

Quindi la roadmap non dovrebbe contare solo "numero di teoremi testati", ma "numero di teoremi con L1-L2-L3 completo".

6.5 Per onboarding di nuovi laboratori

Un laboratorio esterno può entrare nel programma OCT senza conoscere tutta la storia del progetto, se riceve un kit standardizzato:

1. guida iniziale con lessico minimo condiviso;
2. pacchetto PB_min di un claim campione;
3. checklist di replica indipendente;
4. template report con sezione errori obbligatoria.

Questo riduce la barriera d'ingresso e aumenta la probabilità di validazioni indipendenti reali.

7. Limiti e non-claim

Limiti espliciti:

1. il capitolo definisce una baseline metodologica, non l'unica possibile;
2. alcuni domini richiedono metriche ausiliarie altamente specializzate;
3. la regola 2/3 e pragmatica, non dogmatica, e può richiedere adattamento motivato.

Failure mode riconosciuti:

1. benchmark formalmente indipendenti ma semanticamente ridondanti;
2. stress test costruiti troppo deboli per mettere in crisi il claim;
3. rerun usati per "cercare" un esito desiderato;
4. scarsa documentazione dei casi falliti.

Contromisure raccomandate:

1. revisione indipendente del manifest prima dell'esecuzione;
2. quota minima di casi "difficili" in ogni strato;
3. obbligo di pubblicazione dei fallimenti di severità high;
4. audit periodico su coerenza tra preregistrazione e report finale.

Box C - Non-claim

Questo capitolo non implica:

1. che ogni claim debba superare tutti i domini possibili;
2. che la significatività statistica da sola determini la validità teorica;
3. che un benchmark ben progettato sostituisca la necessità di formalizzazione matematica.

8. Claim Ledger (S0-S3)

9. Bridge al Capitolo 14

Il Capitolo 13 ha stabilito come progettare benchmark indipendenti e replicabili, e come trasformare il protocollo in infrastruttura sperimentale.

Il Capitolo 14 completera la milestone v1.4 introducendo la governance epistemica:

1. regole di versioning dei claim;
2. audit trail decisionale;
3. quality gate per release pubbliche;
4. politica di manutenzione del corpus teorematico.

In breve: il Capitolo 13 costruisce la macchina sperimentale; il Capitolo 14 ne definisce la costituzione operativa.

Riferimenti

Riferimenti di framework interno:

1. Ghioni, F. (2026). TE_CORE_v5.1.md.
2. Ghioni, F. (2026). TE_OST_v2.1.md.
3. OCT_VALIDATION_PROTOCOL_v0_1.md.
4. OCT_Theory_and_Theorems/validation/CYCLE_3_2026-04-18/BENCHMARK_MANIFEST_cycle3_v0_1.md.
5. OCT_Theory_and_Theorems/validation/CYCLE_4_2026-04-19/CYCLE_4_REPORT.md.
6. OCT_FOUNDATIONAL_BOOK_CHAPTER_12_v1_0.md.

Riferimenti primari:

1. Popper, K. (1959). The Logic of Scientific Discovery.
2. Lakatos, I. (1978). The Methodology of Scientific Research Programmes.
3. Nosek, B. et al. (2018). The preregistration revolution.
4. Goodman, S., Fanelli, D., Ioannidis, J. (2016). What does research reproducibility mean?.