Sistema agentico | Scrittura | IA modulare

Dalla confusione alla struttura: come progettare un sistema agentico per scrivere testi

Quattro agenti, tre cartucce e un metodo replicabile nella scrittura assistita da IA per gestire stile, struttura e contenuto

(source: Dall-E 3)

Qualche mese fa ci siamo posti un obiettivo: costruire un agente in grado di ricevere informazioni grezze su eventi e organizzarle in forma di cronaca annalistica, sul modello dei grandi cronisti medievali come Giovanni Villani. L’idea sembrava lineare. Un flusso di testi disordinati in ingresso, una cronaca strutturata in uscita. Un agente solo, ben istruito, avrebbe dovuto:

• selezionare i materiali rilevanti secondo certi criteri;
• riorganizzarli secondo la struttura di una cronaca anno per anno;
• scrivere il testo finale con uno stile coerente al modello.

Il primo collaudo ha mostrato il problema: l’agente singolo non reggeva. I materiali venivano selezionati male, la struttura si perdeva, lo stile oscillava. Troppe competenze diverse da concentrare in un’unica testa digitale. Avevamo bisogno di un’architettura diversa.

1 Il sistema a “cartucce”

Un primo passo avanti è arrivato da un ambito completamente diverso: la generazione di immagini. In un progetto precedente avevamo lavorato a un sistema per produrre immagini con IA, con un requisito specifico: mantenere una costanza di stile tra generazioni successive. La soluzione che avevamo adottato era il sistema delle “cartucce”. Funzionava così: Agente A era specializzato nella creazione di “cartucce di stile”. A partire da riferimenti visivi, descrizioni testuali o risposte a domande, costruiva una cartuccia che codificava in modo operativo lo stile desiderato e lo fissava “per sempre”. Agente B riceveva la cartuccia e i contenuti testuali da convertire in immagine, scriveva il prompt e generava l’immagine. Il risultato era che, finché si usava la stessa cartuccia, tutte le immagini mantenevano lo stesso stile. La separazione dei ruoli — chi definisce lo stile, chi lo applica — aveva funzionato. L’idea era trasferibile. Se funzionava per le immagini, poteva funzionare anche per i testi. Ma la scrittura è più complessa della generazione visiva: non c’è solo lo stile, c’è la struttura del testo, c’è l’organizzazione dei materiali, c’è la selezione delle fonti. Serviva un’architettura più articolata.

2 L’architettura generale: quattro agenti, tre cartucce

Abbiamo progettato un sistema a quattro agenti, ciascuno con una responsabilità unica. Il principio guida è lo stesso dell’esperimento grafico: separare i compiti, specializzare gli agenti, farli comunicare attraverso cartucce — oggetti informativi che contengono istruzioni operative.

Il flusso generale è questo:

1. Due agenti “creatori di cartucce” lavorano in parallelo all’inizio. Uno si occupa dello stile, l’altro della struttura. Entrambi, una volta prodotto il loro lavoro, escono di scena.
2. Le cartucce prodotte — tre in totale — vengono passate agli agenti successivi.
3. Un terzo agente riceve una di queste cartucce e i testi grezzi, e li organizza secondo le indicazioni ricevute.
4. Un quarto agente riceve tutto il materiale organizzato più le altre due cartucce, e produce il testo finale.

I quattro agenti hanno nomi poco amichevoli ma funzionali: li abbiamo chiamati CMSTY, CMSTR, TMSM e TMTC. Nei prossimi paragrafi entriamo nel dettaglio di ciascuno, del suo funzionamento interno e delle cartucce che produce. Il caso della cronaca medievale ci accompagnerà come esempio concreto, ma l’architettura è pensata per essere versatile: le stesse cartucce potrebbero descrivere lo stile di un manuale tecnico, di un editoriale o di un post sui social.

3 Agente 1 — CMSTY: l’architetto dello stile

Il primo agente si chiama CMSTY — Style of Text Cartridge Maker. Il suo compito è produrre una cartuccia di stile testuale: un oggetto informativo che codifica in modo operativo come un testo deve essere scritto, indipendentemente da cosa deve dire. La separazione tra come e cosa è il pilastro dell’intera architettura. La cartuccia che CMSTY produce contiene regole sulla forma del testo — lunghezza delle frasi, uso della subordinazione, registro lessicale, tono, presenza dell’autore — ma nessuna indicazione su argomenti, struttura narrativa o ordine degli eventi.

3.1 Come lavora CMSTY

CMSTY riceve dall’operatore input eterogenei: testi di riferimento, descrizioni verbali dello stile desiderato, scorciatoie semantiche (nomi di autori, tradizioni letterarie, aggettivi estetici). Li analizza e li trasforma in regole operative attraverso un processo strutturato in più fasi. L’agente non decide mai da solo: ogni tratto stilistico deve essere esplicitamente confermato dall’operatore.

Analisi dei testi di riferimento. CMSTY scompone ogni testo lungo dodici dimensioni, chiamate assi stilistici (da S00 a S11). Per ogni asse cerca tratti ricorrenti e li annota con una forza di evidenza che misura quanto il tratto sia rappresentativo nel testo analizzato. La scala comprende cinque livelli:

• forte (strong): il tratto è ricorrente in tutto il testo o in più passaggi, abbastanza costante da essere considerato un tratto definitorio.
• moderato‑forte (moderate‑strong): il tratto è un pattern consistente con eccezioni minori; caratterizza lo stile ma non è assoluto.
• moderato (moderate): il tratto è presente e riconoscibile ma non dominante; appare in alcuni passaggi ma non in altri.
• moderato‑debole (moderate‑weak): il tratto è riconoscibile ma poco frequente; può rappresentare una tendenza secondaria.
• debole (weak): il tratto è osservabile in un singolo passaggio o in un numero limitato di casi; potrebbe essere intenzionale o incidentale.

La forza di evidenza viene riportata all’operatore insieme a ogni tratto candidato, ma non determina automaticamente l’inclusione nella cartuccia — la decisione spetta all’operatore. Questa informazione aiuta l’operatore a valutare quanto il tratto sia rappresentativo dello stile complessivo. Se i testi sono più di uno, prima presenta all’operatore ciò che ha trovato in ciascun testo separatamente, poi propone una sintesi evidenziando convergenze e divergenze. Se le contraddizioni superano la metà degli assi pertinenti, l’agente segnala all’operatore che i testi potrebbero rappresentare stili diversi e chiede come procedere: una sola cartuccia limitata ai tratti convergenti, o cartucce separate. Entrando più nel dettaglio, ecco qui di seguito la procedura adottata dall’agente. Quando vengono forniti più testi di riferimento, CMSTY segue una procedura rigorosa per evitare di produrre una sintesi che appiattisca le differenze.

1. Esposizione delle evidenze per testo. Prima di qualsiasi sintesi, l’agente presenta all’operatore, per ogni asse pertinente, ciò che ha trovato in ciascun testo separatamente: il tratto osservato (formulato in termini concreti), la forza di evidenza (secondo la scala a cinque livelli) e un breve esempio. Questa esposizione è obbligatoria e rende visibili le divergenze prima che vengano classificate.

2. Disciplina di classificazione. L’agente distingue nettamente due tipi di differenza:

• Una differenza nella forza di evidenza (es. tratto “forte” nel testo A, “moderato” nel testo B) non costituisce una divergenza: significa che lo stesso tratto è più costante in A che in B.
• Una differenza nel tratto stesso (es. “frasi brevi” in A, “frasi lunghe” in B) è invece una divergenza o una contraddizione, indipendentemente dalla forza di evidenza.

L’agente non deve mai mascherare differenze di tratto come differenze di forza.

3. Soglia di divergenza. Dopo la sintesi comparativa, l’agente conta il numero di assi pertinenti su cui sono state rilevate contraddizioni. Se queste superano la metà degli assi pertinenti, l’agente segnala esplicitamente all’operatore che i testi potrebbero rappresentare profili stilistici diversi e propone due opzioni:

• procedere con un’unica cartuccia limitata ai soli tratti convergenti (ottenendo un profilo più parziale e meno prescrittivo);
• produrre cartucce separate per ciascun testo (o gruppi di testi compatibili), eventualmente seguite da una fusione successiva se si desidera un profilo combinato.

L’agente non prosegue senza una decisione esplicita dell’operatore. Anche quando la soglia non viene superata, ogni contraddizione viene presentata singolarmente e richiede una risoluzione.

Gestione delle scorciatoie semantiche. Se l’operatore fornisce etichette come “stile giornalistico” o “come Calvino”, CMSTY non le lascia come vaghe indicazioni. Le traduce in ipotesi operative mappate sugli assi: “giornalistico può corrispondere a frasi brevi e dichiarative (S01), vocabolario concreto (S03), tono neutro (S08)”. Propone queste ipotesi e attende conferma.

Diagnostic pass. Una serie di confronti tra frasi che esprimono lo stesso contenuto in modi stilisticamente diversi. L’operatore sceglie la versione preferita, e la scelta aggiorna più assi contemporaneamente. È un modo rapido per inferire preferenze senza rispondere a decine di domande.

Adaptive interview. Domande mirate sugli assi che restano indefiniti. Le domande sono a scelta multipla, con possibilità di risposta libera. L’agente seleziona le domande in base allo stato corrente e procede una alla volta.

Verifica di coerenza globale. Prima di produrre la cartuccia, CMSTY controlla che la configurazione di tratti su tutti gli assi sia internamente coerente. Il controllo opera su due livelli:

• Tensioni tra coppie di assi: certe combinazioni producono effetti instabili (ad esempio, frasi molto brevi e alta densità informativa creano un effetto telegrafico; tono neutro e uso frequente di ironia sono in tensione). Se rileva tensioni, le segnala all’operatore e chiede conferma che siano intenzionali.
• Plausibilità del profilo complessivo: l’agente descrive in due o tre frasi il profilo stilistico che emergerebbe dalla configurazione scelta, e chiede all’operatore se corrisponde all’effetto desiderato.

Tensioni irrisolte bloccano la generazione della cartuccia. Vediamo in dettaglio la verifica di coerenza globale su due livelli.

Livello 1 — Rilevamento di tensioni a coppie. L’agente esamina alcune combinazioni note di valori tra assi che possono produrre effetti stilistici instabili o inconsueti. Le coppie attualmente monitorate sono:

• S01 (architettura della frase) × S04 (ritmo): frasi molto brevi con alta densità informativa producono un effetto telegrafico, accettabile solo se intenzionale.
• S01 × S07 (presenza autoriale): frasi molto brevi con interventi autoriali frequenti sono difficili da sostenere; il commento autoriale richiede solitamente spazio sintattico.
• S08 (tono emotivo) × S09 (retorica): tono neutro con uso frequente di figure retoriche (ironia, understatement) crea una contraddizione interna.
• S03 (registro lessicale) × S08: lessico molto semplice con tono solenne è una combinazione rara (possibile, ma va confermata).
• S06 (voce narrante) × S07: voce impersonale con presenza autoriale frequente tira in direzioni opposte; l’agente chiede chiarimenti su come devono coesistere.
• S07 × S08: assenza autoriale con tono ironico; l’ironia richiede quasi sempre una presa di posizione dell’autore; se l’autore non interviene mai, l’ironia deve essere prodotta solo tramite giustapposizione, tecnica specifica che richiede conferma esplicita.

Per ciascuna di queste coppie, se la configurazione corrente presenta una tensione, l’agente la segnala all’operatore, spiegando perché potrebbe produrre un effetto inusuale, e chiede se confermare o rivedere. L’elenco non è esaustivo: l’agente segnala all’operatore qualsiasi combinazione che appaia insolita o potenzialmente instabile, anche se non inclusa sopra.

Livello 2 — Plausibilità del profilo complessivo. Al di là delle singole coppie di assi, l’agente valuta se la configurazione complessiva dei valori produca un profilo stilistico riconoscibile o almeno coerente. Può accadere che valori individualmente validi, combinati tra loro, generino un insieme implausibile (ad esempio: architettura frasale complessa, lessico semplice, voce impersonale, retorica frequente e ritmo uniforme). In questi casi, l’agente descrive in due o tre frasi il profilo risultante e lo sottopone all’operatore: “Lo stile che hai definito produrrebbe una prosa che [descrizione]. È questo l’effetto desiderato?”

Regola interpretativa. La verifica di coerenza non impone un’unica nozione di plausibilità stilistica: il suo ruolo è rilevare tensioni e combinazioni rare, non rifiutarle automaticamente. Quando emergono tensioni, l’agente le espone, spiega perché potrebbero generare un profilo insolito o instabile e chiede all’operatore se intende conservarle o modificarle. Una combinazione rara è considerata valida se esplicitamente confermata. Le tensioni non risolte bloccano la generazione della cartuccia.

3.2 I dodici assi dello stile

Gli assi sono raggruppati in cinque blocchi funzionali. Non tutti sono pertinenti per ogni genere: CMSTY può marcare un asse come not_applicable.

Architettura — come il testo è costruito S00: architettura del paragrafo (lunghezza, densità tematica, chiusura) S01: architettura della frase (lunghezza, subordinazione, posizione del verbo) S02: transizioni e connettivi (come ci si muove tra le idee)

Tessitura — con cosa è costruito S03: registro lessicale (formale/informale, astratto/concreto, tecnico/comune) S04: ritmo e velocità (variazioni, punteggiatura, densità informativa) S05: tessitura fonetica (allitterazioni, assonanze, attenzione al suono)

Voce — chi parla S06: voce narrante (persona, distanza, rapporto col lettore) S07: presenza autoriale (interventi espliciti, commenti, giudizi)

Effetto — cosa produce nel lettore S08: tono emotivo (dominante, stabile o variabile) S09: retorica operativa (ironia, understatement, iperbole, giustapposizione)

Specializzati S10: trattamento delle fonti (citazioni, attribuzioni) — opzionale S11: modulazione del registro (come lo stile cambia a seconda dell’argomento)

3.3 La cartuccia di stile: cosa produce CMSTY

Alla fine del processo, CMSTY genera un documento in formato ATON che chiamiamo cartuccia di stile testuale. È un oggetto informativo autonomo, pensato per essere letto e applicato da un agente a valle (nel nostro sistema, il quarto agente, TMTC). La struttura è stabile e indipendente dal contenuto specifico.

Una cartuccia di stile contiene:

Identità e provenienza - id univoco e versione

• stato (draft, confirmed)
• modalità di creazione (creazione, refinement, fusione)
• fonte dei tratti (testi analizzati, cartucce sorgente)
• per ogni tratto confermato: forza di evidenza e data di conferma
• storico dei tratti rifiutati (con motivo)
• eventuale storia di raffinamenti e fusioni

Questa sezione garantisce la tracciabilità: ogni decisione stilistica è documentata e riconducibile alla sua origine.

Priorità Un elenco sintetico (5–6 voci) delle caratteristiche dominanti dello stile. Serve come orientamento rapido per chi legge la cartuccia, ma non sostituisce le regole dettagliate.

Assi stilistici Per ogni asse definito (non tutti devono esserlo), la cartuccia contiene:

• un trait: descrizione del tratto in linguaggio naturale
• una regola operativa: formulazione che un agente può applicare senza ambiguità
• controesempi: cosa evitare, per delimitare il confine del tratto

Le regole sono sempre formulate in termini di come si scrive, mai di cosa si scrive.

Test di validazione Una serie di condizioni verificabili che il testo finale deve soddisfare. Ogni test include:

• un riferimento alla regola o all’asse che testa
• una descrizione del criterio
• una formulazione operativa (es. “le frasi hanno in media meno di 15 parole”, non “il testo scorre bene”)

I test servono sia come guida per l’agente che scrive, sia come strumento di verifica a posteriori.

3.4 Proprietà fondamentali della cartuccia

Una cartuccia ben fatta possiede tre caratteristiche:

• Autosufficienza: non richiede accesso ai testi originali da cui lo stile è stato estratto. Tutto ciò che serve per applicare lo stile è contenuto nella cartuccia.
• Operatività: ogni regola è formulata in modo che un agente possa applicarla senza ambiguità. Etichette generiche come “elegante” o “fluido” non sono ammesse.
• Indipendenza dal contenuto: la cartuccia non contiene istruzioni su cosa scrivere, in che ordine, o su quali argomenti. Definisce esclusivamente la forma.

3.5 I tre modi operativi

CMSTY può lavorare in tre modalità, a seconda di ciò che l’operatore gli fornisce: creazione, raffinamento e fusione. Queste modalità estendono la flessibilità del sistema, permettendo di raffinare progressivamente uno stile o di creare nuovi stili ibridi a partire da definizioni esistenti. In tutti e tre i casi, l’output è sempre una cartuccia di stile, pronta per essere usata dagli agenti a valle.

3.5.1 Creazione

Si parte da zero con testi di riferimento, descrizioni, scorciatoie semantiche. È la modalità che abbiamo usato nel nostro esperimento.

3.5.2 Raffinamento

Il raffinamento consente di aggiornare una cartuccia già esistente e confermata attraverso l’analisi di nuovi testi di riferimento. La cartuccia esistente funge da baseline dominante: i suoi tratti rimangono in vigore, salvo che le nuove evidenze forniscano ragioni specifiche per modificarli. L’agente confronta la baseline con i nuovi testi, classifica gli esiti (confermato, arricchito, contraddetto, nuovo asse) e propone all’operatore le eventuali modifiche. Il processo segue questi passaggi: 1 — Caricamento: viene caricata la cartuccia confermata (baseline) e i nuovi testi. 2 — Analisi: i nuovi testi vengono analizzati asse per asse con il consueto protocollo. 3 — Confronto: per ogni asse con nuove evidenze, l’agente classifica l’esito in una di quattro categorie: confermato (il nuovo testo mostra lo stesso comportamento già definito; arricchito ( il nuovo testo aggiunge sfumature compatibili con la definizione esistente; contraddetto (il nuovo testo presenta tratti incompatibili); nuovamente definito ( il nuovo testo fornisce evidenza per un asse precedentemente non definito o marcato come non applicabile). 4 — Presentazione: i risultati sono mostrati all’operatore per categorie (prima le contraddizioni, poi gli arricchimenti, poi i nuovi assi). Per ogni modifica proposta vengono mostrati il tratto corrente, le nuove evidenze con forza, la modifica proposta e un controesempio. 5 — Decisioni: l’operatore conferma, modifica o rifiuta ogni cambiamento. Le proposte rifiutate vengono registrate nella provenienza. 6 — Ricontrollo di coerenza: dopo le modifiche, viene eseguita una verifica di coerenza limitata agli assi modificati. 7 — Aggiornamento: la cartuccia viene aggiornata (versione incrementata), con registrazione delle modifiche nella sezione PROVENANCE. Anche i test di validazione vengono rivisti se necessario.

3.5.3 Fusione

La fusione combina due o più cartucce confermate in una nuova cartuccia armonizzata. Tutte le cartucce di partenza sono trattate come peer simmetrici. L’agente confronta asse per asse, classifica (convergente, divergenza compatibile, contraddizione), e chiede all’operatore di risolvere i conflitti. Il processo prevede i seguenti passaggi: 1 — Caricamento: vengono caricate due o più cartucce confermate. 2 — Confronto asse per asse: per ogni asse, l’agente classifica l’esito in: convergente (tutte le cartucce definiscono tratti compatibili sull’asse; questi entrano direttamente nella nuova cartuccia); divergenza compatibile (definiscono tratti diversi che possono coesistere attraverso modulazione contestuale; l’agente propone una strategia di armonizzazione e chiede conferma all’operatore); contraddizione (definiscono tratti inconciliabili; si richiede scelta all’operatore). 3 — Presentazione: vengono mostrate convergenze, divergenze con strategie di armonizzazione, e contraddizioni con alternative. 4 — Risoluzione: l’operatore risolve tutte le divergenze e contraddizioni, scegliendo tra le opzioni proposte (es. adottare un tratto, alternanza contestuale, compromesso). 5 — Verifica di coerenza globale: una volta risolti tutti gli assi, viene eseguita la verifica di coerenza globale sull’intero profilo armonizzato. 6 — Generazione: viene prodotta una nuova cartuccia indipendente (con proprio ID, versione 1.0, e nuova sezione VALIDATION_TESTS). Le decisioni di fusione sono registrate nella provenienza.

4. Agente 2 — CMSTR: lo strutturista

Il secondo agente si chiama CMSTR — Structure of Text Cartridge Maker. Il suo compito è definire come l’informazione è organizzata all’interno del testo finale, in totale indipendenza dallo stile con cui verrà scritto e dai contenuti specifici che verranno raccontati. Mentre CMSTY si occupa della forma espressiva, CMSTR si occupa dell’architettura informativa: quali unità compongono il testo, in che ordine si susseguono, come si relazionano tra loro, come si aprono e come si chiudono, quali elementi accessori (titoli, note, rimandi) le accompagnano. Anche in questo caso vale la separazione rigorosa:

• struttura → organizzazione dell’informazione;
• stile → forma espressiva;
• contenuto → informazione trattata. L’agente CMSTR definisce cosa deve esserci e dove, mai come si scrive né cosa si racconta.

4.1 Due cartucce in sequenza

CMSTR produce due cartucce in ordine fisso: 1 — Structure of Text (primaria): definisce l’architettura del testo finale. È il documento principale, quello su cui l’operatore lavora direttamente; 2 — Structure of Source (derivata): definisce come devono essere organizzati i materiali in ingresso per poter alimentare correttamente quella struttura. Deriva dalla primaria e non può essere confermata indipendentemente. La logica è la seguente: una volta stabilito come sarà fatto il testo finale, si può determinare di quali informazioni ha bisogno e in che forma devono arrivare. La cartuccia derivata è un mandato per chi prepara i materiali grezzi (nel nostro sistema, il terzo agente, TMSM).

4.2 Come lavora CMSTR

Come CMSTY, anche CMSTR può operare in tre modalità: creazione, raffinamento e fusione. In tutti i casi, l’agente non decide mai da solo: ogni regola strutturale deve essere esplicitamente confermata dall’operatore. — Creazione da testi di riferimento — CMSTR analizza i testi forniti lungo dodici assi strutturali (T00–T11), che coprono l’intera architettura del testo: dallo schema globale (T00) fino agli apparati di navigazione come titoli e note (T11). Per ogni asse cerca regole ricorrenti, le annota con una forza di evidenza (forte, moderata, debole) e le propone all’operatore. Con più testi, prima presenta le evidenze per ciascuno separatamente, poi sintetizza convergenze, divergenze compatibili e contraddizioni. — Creazione ex novo (da brief) — Se l’operatore non ha testi di riferimento ma solo un’idea generale, CMSTR può lavorare a partire da un repertorio tipologico che raccoglie modelli strutturali ricorrenti nella tradizione della prosa: annalistico, cronachistico, saggistico, enciclopedico, giornalistico, narrativo lineare, narrativo non lineare, e altri. L’operatore indica una tipologia come base, e l’agente la traduce in vincoli sugli assi T, da confermare uno per uno. Il repertorio è un punto di partenza, non una risposta automatica. — Conferma e forza dei vincoli — Ogni regola strutturale deve dichiarare la propria forza:

• mandatory: nessuna eccezione ammessa;
• preferred: applicata di default, eccezioni motivate consentite;
• optional: può essere applicata o omessa
• forbidden: esclude esplicitamente un’opzione La forza è parte della regola, non un metadato: il destinatario a valle la usa per determinare il proprio margine di manovra. — Controesempi — Come per lo stile, ogni regola significativa deve essere accompagnata da un esempio positivo e da un controesempio che mostra la stessa informazione organizzata diversamente. Insieme definiscono il confine operativo della regola.

Il repertorio tipologico raccoglie modelli strutturali ricorrenti nella tradizione della prosa. Ciascun modello è una configurazione ricorrente di valori su più assi, non un’etichetta di genere. I modelli attualmente inclusi sono:

• Annalistico: unità: voce per anno, registrazione breve. Sequenza: cronologica anno per anno. Tratti: concisione, registrazione su interpretazione, continuità temporale.
• Cronachistico: unità: eventi in serie, blocchi narrativi per argomento. Sequenza: cronologica con raggruppamenti tematici interni. Tratti: ampiezza locale, dettaglio circostanziato, narrazione continua.
• Diaristico: unità: voci datate. Sequenza: temporale (giorno per giorno o a intervalli regolari). Tratti: forma autobiografica, registrazione di attività e riflessioni, immediatezza.
• Epistolare: unità: lettere o documenti con mittente, destinatario, data. Sequenza: per data o ordine di spedizione. Tratti: polifonia di voci, montaggio di documenti.
• Saggistico: unità: introduzione (tesi), corpo argomentativo, conclusione. Sequenza: logico-argomentativa. Tratti: progressione attraverso ragioni, esempi ed evidenze.
• Enciclopedico: unità: lemma (titolo, definizione, sviluppo), apparato di rinvii. Sequenza: alfabetica o per categorie. Tratti: forte ruolo di rinvii e indici.
• Giornalistico: unità: titolo, attacco (lead), dettagli e contesto. Sequenza: importanza decrescente. Tratti: ottimizzato per lettura rapida e tagli redazionali.
• Trattatistico: unità: parti, capitoli, sezioni con definizioni, distinzioni, argomenti. Sequenza: gerarchica e sistematica. Tratti: tassonomie esplicite, struttura ad albero.
• Narrativo lineare: unità: scene, episodi. Sequenza: cronologica. Tratti: coincidenza tra ordine degli eventi e ordine della narrazione.
• Narrativo non lineare: unità: scene, episodi. Sequenza: con anacronie (analessi, prolessi). Tratti: scarto deliberato tra ordine degli eventi e ordine della narrazione.

In modalità ex novo, l’operatore può indicare una tipologia come base; l’agente la traduce in vincoli operativi sugli assi T, che l’operatore conferma, modifica o integra uno per uno. Il repertorio è un punto di partenza, non una risposta automatica: l’agente non assegna mai un’etichetta di genere alla cartuccia finale, ma solo regole operative derivate dal modello scelto.

4.3 I dodici assi strutturali (T00–T11)

Durante l’analisi di un testo di riferimento, CMSTR esamina ogni asse strutturale ponendosi domande specifiche, che guidano l’estrazione di regole operative. Non tutti gli assi saranno informativi in ogni testo; l’agente si concentra su quelli per cui il testo offre evidenze. Gli assi sono organizzati in quattro blocchi funzionali: architettura globale; relazioni e gerarchia; contenuto e granularità; confini e apparati.

4.3.1 Blocco 1 — Architettura globale

• T00: schema globale — il testo segue uno schema riconoscibile (annalistico, saggistico, narrativo, ecc.)? Lo schema è puro o ibrido? Quali vincoli di genere impone?
• T01: unità compositive — quali sono i mattoni del testo (capitoli, sezioni, scene, blocchi tematici)? A quanti livelli gerarchici operano? Come si riconoscono i confini tra unità? Le unità sono omogenee o eterogenee?
• T02: principio di sequenza — quale logica governa l’ordine delle unità (cronologica, tematica, causale, gerarchica, per importanza, a spirale)? Il principio è uniforme o cambia a diversi livelli? Esistono eccezioni sistematiche?

4.3.2 Blocco 2 — Relazioni e gerarchia

• T03: relazioni tra unità — come si collegano le unità? Quali relazioni dominano (elaborazione, evidenza, contrasto, causa, contesto)? Le relazioni sono esplicite o implicite?
• T04: gerarchia informativa — cosa viene trattato come essenziale e cosa come accessorio? Dove si collocano le informazioni di sfondo? La distinzione è stabile o varia?
• T05: progressione tematica — come vengono introdotti i temi? Come vengono mantenuti, sospesi e ripresi? Ci sono ricapitolazioni, rinvii interni, esempi ricorrenti? Come viene garantita la coerenza a lunga distanza?

4.3.3 Blocco 3 — Contenuto e granularità

• T06: granularità informativa — quanto dettaglio contiene ogni unità? Il livello di dettaglio è uniforme o variabile? Dove il testo si espande e dove si comprime? La variazione segue un criterio riconoscibile?
• T07: regime di supporto — quanto e dove compaiono esempi, evidenze, citazioni, dati? Qual è la loro relazione con il nucleo dell’unità? Il supporto è sistematico o episodico?
• T08: trattamento dell’incompletezza — come gestisce il testo le lacune informative? Le segnala, le aggira, le ignora? Come tratta i dati incerti o contraddittori? Esistono meccanismi espliciti (formule cautelative, note, rinvii)?

4.3.4 Blocco 4 — Confini e apparati

• T09: aperture di unità — come inizia ogni unità? Quali elementi sono obbligatori all’apertura (data, titolo, contesto, riferimento a occorrenze precedenti)? L’apertura orienta il lettore? Colloca l’unità nel testo complessivo?
• T10: chiusure di unità — come finisce ogni unità? Chiude, sospende o rilancia? Prepara ciò che segue? Contiene un rinvio esplicito? I pattern di chiusura sono formulari o variabili?
• T11: apparato strutturale — il testo ha titoli, indici, note, sistemi di rinvio? Come sono organizzati? Che funzione svolgono (orientamento, navigazione, approfondimento, meta‑organizzazione)?

Non tutti gli assi sono pertinenti per ogni tipo di testo. CMSTR può marcare un asse come not_applicable. L’agente si concentra sugli assi per cui il passaggio offre evidenza. Le risposte a queste domande producono candidate rule per ciascun asse, che vengono poi presentate all’operatore con un livello di vincolo (mandatory, preferred, optional, forbidden) ed eventualmente una forza di evidenza (forte, moderata, debole) in base alla ricorrenza nel testo. In caso di più testi, si applica la stessa procedura di sintesi comparativa già descritta per lo stile. Quando vengono forniti più testi di riferimento, CMSTR applica lo stesso principio di sintesi comparativa già visto per lo stile: prima presenta all’operatore le evidenze per ciascun testo separatamente, poi produce una sintesi che identifica convergenze, divergenze compatibili e contraddizioni. Le contraddizioni vengono sempre sottoposte all’operatore per la risoluzione.

4.4 La cartuccia primaria: Structure of Text

La cartuccia di struttura del testo è organizzata in sette sezioni. La struttura è stabile e indipendente dal contenuto specifico. 1 — Sezione A — Identità — Nome, versione, data, modello di riferimento (se presente), uso previsto. 2 — Sezione B — Sintesi strutturale — Descrizione ad alto livello dello schema globale, del principio di sequenza, del tipo di unità, della gerarchia. Serve come orientamento rapido, non sostituisce le regole operative. 3 — Sezione C — Architettura e composizione — Regole operative su T00, T01, T02. Ogni regola con esempio, controesempio e forza dichiarata. 4 — Sezione D — Relazioni e gerarchia — Regole su T03, T04, T05. 5 — Sezione E — Contenuto e granularità — Regole su T06, T07, T08. 6 — Sezione F — Confini e apparati — Regole su T09, T10, T11. 7 — Sezione G — Galleria di esempi — 6-10 schemi strutturali che mostrano l’organizzazione applicata a contenuti diversi. Sono dimostrazioni, non testi finali.

4.5 La cartuccia derivata: Structure of Source

Una volta confermata la cartuccia primaria, CMSTR deriva la seconda cartuccia percorrendo i seguenti sette assi (F00–F06), che traducono i vincoli del testo in requisiti per i materiali in ingresso. La domanda guida è: dato il vincolo T, di cosa ha bisogno il materiale per poterlo soddisfare?

F00 — Unità informativa minima (chunk) Il tipo di unità atomica richiesta: evento, argomento, definizione, esempio, dato. Deriva da T00 e T01.

F01 — Campi obbligatori Attributi che ogni chunk deve avere. Per un evento: tempo, luogo, attori, fonte. Per un argomento: tesi, premesse, evidenze. Deriva da T01 e T06.

F02 — Tassonomia funzionale Ogni chunk deve essere classificabile per ruolo strutturale: nucleo, supporto, contesto, transizione, digressione. Deriva da T04 e T07.

F03 — Granularità del chunk Il livello di dettaglio richiesto. Deriva da T06.

F04 — Relazioni tra chunk Legami che devono essere rappresentabili tra i chunk (successione, causa, contesto, aggregazione). Deriva da T03.

F05 — Provenienza e affidabilità Se il testo deve gestire l’incompletezza (T08), i chunk devono portare indicazioni minime di fonte e livello di confidenza.

F06 — Copertura e gap Mappa di quali slot strutturali sono coperti e quali no. Deriva dall’insieme dei T.

La cartuccia derivata ha sei sezioni (dalla A alla F) e dipende esplicitamente dalla primaria: non può essere confermata se la primaria non è confermata, e torna automaticamente in bozza se la primaria viene riaperta e modificata.

4.5.1 Gerarchia dei chunk: atomici e aggregati

Un aspetto centrale della cartuccia derivata è la definizione della gerarchia dei chunk, specificata nell’asse F00. I chunk si distinguono in due tipi fondamentali:

• Chunk atomico: rappresenta un singolo nucleo informativo minimo (un evento elementare, un dato, una definizione). Non può contenere altri chunk al suo interno. Il suo campo children è obbligatoriamente un array vuoto: children: [].
• Chunk aggregato: rappresenta una collezione strutturata di chunk atomici (ad esempio un quadro di stato composto da più dati, o una sequenza di eventi correlati). Contiene uno o più chunk figli, referenziati tramite i loro ID nel campo children. Deve essere scomponibile nei suoi componenti, e ciascun figlio deve essere a sua volta un chunk valido.

La profondità massima di annidamento consigliata è di 2–3 livelli, per evitare complessità eccessiva nella strutturazione dei materiali.

Questa gerarchia ha implicazioni dirette per TMSM, l’agente che riceve la cartuccia derivata:

• durante la segmentazione del materiale grezzo, TMSM deve determinare se una porzione di testo corrisponde a un chunk atomico o aggregato, seguendo le indicazioni della cartuccia e gli esempi in SAMPLE_GALLERY;
• se un’unità informativa contiene più nuclei (violando la regola F03–4), TMSM deve suddividerla in chunk atomici separati;
• nel costruire l’output, ogni chunk (atomico o aggregato) deve includere il campo children, rispettando la gerarchia definita.

La presenza esplicita della gerarchia nei chunk permette di mantenere relazioni strutturali chiare tra le informazioni, e costituisce la base per le relazioni di aggregazione (contains/part_of) che verranno successivamente utilizzate da TMTC per costruire l’architettura del testo finale.

4.5.2 Vocabolario controllato delle relazioni

L’asse F04 richiede che le relazioni tra chunk siano dichiarate in modo esplicito e utilizzino un vocabolario controllato. Questo garantisce che le relazioni siano interpretabili in modo univoco da tutti gli agenti della pipeline, in particolare da TMSM (che le costruisce) e da TMTC (che le utilizza per organizzare il testo).

Il vocabolario è organizzato in cinque categorie semantiche, ciascuna con i propri sottotipi: - temporale (before, after, during, overlaps);

• causale (cause, effect, enables, prevents);
• contrastiva (contrast, contradiction);
• esplicativa (explains, justifies, exemplifies);
• parallela (parallel, analogy).

A queste si aggiungono le relazioni strutturali di aggregazione, che codificano la gerarchia dei chunk:

- aggregazione (contains, part_of)

Le relazioni di aggregazione hanno una funzione specifica: un chunk aggregato contains i suoi figli; ogni figlio è part_of il suo genitore. Queste relazioni sono fondamentali per mantenere la coerenza gerarchica dell’informazione.

Regole d’uso:

• Ogni relazione deve utilizzare esclusivamente termini appartenenti a questo vocabolario. L’uso di testo libero (es. “è collegato a”, “si riferisce a”) è vietato.
• Le relazioni possono collegare chunk non adiacenti nella sequenza temporale o testuale.
• Le interpretazioni (commenti, giudizi, spiegazioni) devono essere ancorate al chunk a cui si riferiscono tramite una relazione esplicita, di solito di tipo esplicativo (explains, justifies) o contrastivo.
• Quando un chunk è in relazione con più chunk, tutte le relazioni devono essere dichiarate esplicitamente.

Questo vocabolario controllato, combinato con la gerarchia dei chunk (atomici/aggregati) e il registro attori, costituisce l’infrastruttura che permette a TMTC di ricostruire fedelmente l’architettura informativa del testo finale, senza ambiguità interpretative.

4.5.3 Registro attori: tracciabilità e univocità dei riferimenti

Un elemento fondamentale della cartuccia di struttura delle fonti è la gestione degli attori (persone, gruppi, istituzioni, organizzazioni) menzionati nei materiali. L’asse F01 richiede che ogni chunk includa un campo actors contenente una lista di riferimenti agli attori coinvolti. Tali riferimenti non devono essere espressi come testo libero, ma puntano a un registro attori condiviso, costruito da TMSM durante l’elaborazione. Si ottengono così identificatori stabili per entità nominate.

Nella cartuccia è definito lo schema del registro attori, che include alcuni campi con i relativi obblighi:

• id (identificatore unico stabile (es. ACT001)), mandatory;
• name (nome canonico dell’attore), mandatory;
• type (categoria (persona, istituzione, gruppo, organizzazione)), mandatory;
• attributes (proprietà aggiuntive (ruolo, affiliazione, periodo di attività, descrizione)), optional.

Procedura di costruzione del registro (operata da TMSM):

1. Durante la segmentazione del materiale grezzo, TMSM identifica tutte le occorrenze di attori.
2. Assegna un id stabile a ogni attore unico.
3. Popola nome, tipo e attributi dalle evidenze disponibili.
4. Quando lo stesso attore è menzionato con nomi varianti (es. “Carlo Magno”, “Carlomagno”, “imperatore Carlo”), li unifica sotto un unico id con nome canonico.
5. Nei campi actors dei chunk, inserisce solo gli id (es. actors: [“ACT001”, “ACT003”]), mai il testo libero.

Questo meccanismo garantisce:

• Univocità: ogni attore è referenziato in modo coerente in tutti i chunk.
• Tracciabilità: è possibile ricostruire tutte le occorrenze di un attore nei materiali.
• Indipendenza dalla lingua: il nome canonico può essere in una lingua, ma l’id è stabile.
• Preparazione per TMTC: durante la scrittura del testo finale, TMTC risolverà gli id in nomi (eventualmente scegliendo tra varianti) secondo le regole stilistiche, ma la struttura informativa rimane chiara.

L’obbligo di usare ID stabili, anziché testo libero, è uno dei pilastri della tracciabilità dell’intera pipeline: ogni informazione strutturata mantiene un legame esplicito con le entità del mondo reale a cui si riferisce, senza ambiguità lessicali. Il registro attori è incluso nell’output di TMSM come blocco separato (ACTOR_REGISTRY) e viene utilizzato da TMTC per garantire la coerenza dei riferimenti nel testo finale.

4.5.4 I test di validazione

Entrambe le cartucce prodotte da CMSTR includono una sezione obbligatoria chiamata VALIDATION_TESTS, che contiene criteri verificabili per accertare che un testo (o un insieme di materiali strutturati) sia conforme alle regole definite nella cartuccia. Questi test non sono solo esempi, ma veri e propri strumenti di validazione utilizzati a valle da TMSM (per la cartuccia derivata) e da TMTC (per la cartuccia primaria).

Ogni test è un oggetto strutturato con sette campi obbligatori:

• id -Identificatore univoco del test (es. VT01, VT02);
• axis -L'asse strutturale oggetto del test (T00–T11 o F00–F06);
• rule_reference -Identificatore della regola specifica che il test verifica;
• description -Spiegazione in linguaggio naturale di cosa verifica il test;
• example -Esempio di output conforme che supera il test;
• counter_example -Esempio di output non conforme che fallisce il test;
• test_criterion -Condizione operativa e verificabile che distingue conformità da violazione (es. "ogni unità inizia con un indicatore temporale esplicito", non "il testo è ben organizzato").

Requisiti quantitativi: il numero di test deve essere almeno pari al numero di assi che contengono almeno una regola mandatory. Questo significa che ogni vincolo strutturale obbligatorio deve essere accompagnato da almeno un criterio di verifica. Una cartuccia con meno test di quanti siano gli assi con regole mandatory è da considerarsi non conforme.

Per la cartuccia derivata (Structure of Source), si applicano gli stessi requisiti. Inoltre, i test devono coprire i casi critici come la rappresentazione di gap informativi e la corretta costruzione dei chunk aggregati.

La presenza di VALIDATION_TESTS rende le cartucce auto-validanti: un agente a valle (TMSM o TMTC) può eseguire tutti i test in modo automatico e produrre un report di conformità. Questo meccanismo, già descritto per CMSTY, è qui applicato al dominio strutturale, con la stessa funzione di garantire che l'output finale rispetti fedelmente le decisioni prese in fase di definizione della struttura.

4.6 Nel nostro esperimento

Per la cronaca medievale, abbiamo usato CMSTR in modalità creazione con testi di riferimento (Villani). Dalla loro organizzazione annalistica — eventi raggruppati per anno, progressione cronologica, aperture con data, chiusure con rinvio o commento — l’agente ha estratto le regole che sono poi confluite nella cartuccia primaria Chronicle Sequential Event Structure. Da quella cartuccia, CMSTR ha derivato la cartuccia secondaria Chronicle Informational Source Structure, che specifica come devono essere organizzati i materiali grezzi: ogni evento deve arrivare con data, attori, luogo (campi obbligatori), deve essere classificabile per ruolo (evento, contesto, conseguenza), e deve poter gestire lacune e incertezze. Queste due cartucce — insieme a quella di stile prodotta da CMSTY — passeranno ora agli agenti successivi. Ma prima di arrivare al testo finale, i materiali grezzi devono essere trasformati in “materia prima ordinata” secondo le indicazioni della cartuccia derivata. Questo è compito del terzo agente.

5 Agente 3 — TMSM: il gestore delle fonti

Il terzo agente si chiama TMSM — Souce of Text Manager. Il suo compito è ricevere i testi grezzi e trasformarli in materia prima ordinata, pronta per essere utilizzata dall’agente che scriverà il testo finale. Mentre i primi due agenti lavoravano sulla definizione di regole astratte (stile e struttura), TMSM opera sul concreto: prende i materiali disordinati che costituiscono l’input del sistema e li organizza secondo le indicazioni ricevute dalla cartuccia di struttura delle fonti prodotta da CMSTR.

5.1 Schema-first processing

Il principio fondamentale di TMSM è schema-first: tutta la logica di strutturazione viene dalla cartuccia, mai dall’agente. TMSM non inventa nulla, non decide autonomamente come organizzare i materiali, non introduce categorie che non siano già previste. La cartuccia è l’unica autorità che definisce la struttura.

Questo significa che TMSM deve essere in grado di:

• caricare e interpretare una cartuccia in formato ATON, con tutte le sue sezioni
• estrarre le regole da applicare, distinguendo il livello di obbligo (mandatory, preferred, optional, forbidden)
• popolare lo schema usando le informazioni estratte dai testi grezzi
• rispettare i vincoli senza mai modificarli o reinterpretarli

5.2 Cosa riceve TMSM

L’agente riceve due input:

1. I testi grezzi: il materiale non strutturato che deve essere organizzato (nel nostro caso, le fonti sulla cronaca medievale)
2. La cartuccia di struttura delle fonti: prodotta da CMSTR, che definisce come i materiali devono essere organizzati

Se la cartuccia è mancante, malformata o non interpretabile, TMSM si ferma e richiede una cartuccia valida. Non procede mai in assenza di schema.

5.3 Come lavora TMSM

Il processo di TMSM è articolato in una sequenza di passaggi ben definiti, ciascuno con un obiettivo specifico.

5.3.1 Caricamento della cartuccia

TMSM analizza la cartuccia in formato ATON, estraendo le cinque sezioni canoniche:

• IDENTITY: identificativo, versione, stato, dipendenze
• PROVENANCE: fonte di derivazione, conferme operatore
• AXES: tutte le regole strutturali raggruppate per asse (F00–F06)
• SAMPLE_GALLERY: pattern di riferimento per la forma dell’output
• VALIDATION_TESTS: criteri di accettazione da verificare a posteriori

Per ogni regola, legge il campo constraint e classifica il livello di obbligo:

• mandatory: deve essere soddisfatta — la violazione è un errore strutturale;
• preferred: dovrebbe essere soddisfatta — l’omissione richiede giustificazione;
• optional: può essere soddisfatta — nessun obbligo;
• forbidden: non deve verificarsi — la presenza è un errore strutturale. Costruisce un indice interno delle regole per poterle consultare rapidamente durante l’elaborazione.

5.3.2 Segmentazione del materiale

I testi grezzi vengono suddivisi in candidate information units: frasi, proposizioni, frammenti strutturati, elementi di elenco, voci tabellari, date, entità nominate. Per ogni unità, TMSM identifica:

• riferimenti temporali
• attori menzionati
• luoghi citati
• affermazioni fattuali vs interpretazioni
• TMSM deve segmentare l’intero materiale testuale ricevuto in input, senza omettere alcuna parte. Ogni frase, voce di elenco, data, entità nominata o altro elemento testuale deve essere considerato come candidato per la costruzione di un chunk. La segmentazione non deve lasciare porzioni di testo non processate.

Questo requisito garantisce che l’output strutturato rappresenti fedelmente la totalità dell’informazione disponibile, e che le eventuali lacune vengano rappresentate esplicitamente come chunk di gap (epistemic_status: "missing"), non come omissioni silenziose. La completezza della copertura è verificata nella fase di validazione attraverso i test della cartuccia (F06‑1, F06‑2).

5.3.3 Costruzione del registro attori

Prima di creare i chunk veri e propri, TMSM costruisce un registro degli attori condiviso:

• scandisce tutte le unità candidate alla ricerca di menzioni di attori (persone, istituzioni, gruppi, altre entità nominate)
• unifica le varianti dello stesso attore sotto un unico identificativo canonico
• assegna un id stabile a ciascun attore (es. ACT001, ACT002)
• popola lo schema attore: id, nome, tipo, attributi

Il registro diventa una struttura dati condivisa: tutti i successivi riferimenti a attori nei chunk useranno esclusivamente gli id del registro, mai il testo libero.

5.3.4 Istanziazione dei chunk

Per ogni unità informativa candidata:

• determina il tipo di chunk (evento, stato, gap, ecc.) in base alle regole della cartuccia e ai pattern di SAMPLE_GALLERY
• determina il livello del chunk:
• atomico: singolo nucleo informativo → children: []
• aggregato: collezione strutturata → children: [id1, id2, ...]
• verifica la regola F03–4: un chunk atomico deve contenere esattamente un nucleo. Se un’unità contiene più nuclei, viene suddivisa in chunk separati.
• popola i campi base:
• id (generato univoco)
• type (tipo definito dalla cartuccia)
• level (atomic o aggregate)
• children ([] per atomici, id figli per aggregati)
• time (riferimento temporale estratto)
• actors (lista di id dal registro attori)
• place (luogo estratto)
• epistemic_status (factual, uncertain, missing)
• role (core, support, context)
• popola i campi dipendenti dal tipo come definito dagli assi della cartuccia

5.3.5 Assegnazione dello statuto epistemico

Ogni chunk riceve un epistemic_status a livello di chunk, non di campo:

• factual: l’informazione è esplicitamente attestata e supportata;
• uncertain: l’informazione è parzialmente supportata, inferita o contestata;
• missing: nessuna evidenza — questo chunk rappresenta una lacuna documentaria

5.3.6 Campo confidence (livello di confidenza)

Oltre allo statuto epistemico (epistemic_status), ogni chunk riceve un campo confidence che esprime il grado di affidabilità dell’evidenza da cui è stato estratto. I valori possibili sono tre:

• high: l’informazione è esplicitamente attestata nella fonte, con elementi chiari e non contraddetti;
• medium: l’informazione è supportata ma con qualche ambiguità, o proviene da una fonte secondaria, o è inferita con buona probabilità;
• low: l’informazione è incerta, poco documentata, o si basa su indizi deboli; per i gap informativi (epistemic_status: "missing") il valore è tipicamente low. Il livello di confidenza è determinato da TMSM sulla base della qualità e della ricorrenza dell’evidenza nei materiali sorgente. Questo campo aiuta TMTC a decidere come formulare l’informazione nel testo finale (ad esempio, un chunk con confidence: low potrebbe richiedere un’espressione più cauta anche se classificato come factual). La distinzione tra epistemic_status (certezza ontologica: il fatto esiste o meno) e confidence (affidabilità dell’evidenza) consente una resa più sfumata della realtà documentaria.

5.3.7 Assegnazione del ruolo funzionale

Ogni chunk riceve un role:

• core: centrale nella struttura informativa;
• support: fornisce evidenza o dettaglio per un’unità core;
• context: informazione di sfondo, cornice, ambientazione. Il ruolo deve essere coerente con la gerarchia informativa (F02–2): un dato secondario non può essere classificato come core.

5.3.8 Costruzione delle relazioni

TMSM crea relazioni tra chunk utilizzando esclusivamente il vocabolario controllato definito dalla cartuccia: — Relazioni semantiche — temporali (before, after, during, overlaps); causali (cause, effect, enables, prevents); contrastive (contrast, contradiction); esplicative (explains, justifies, exemplifies); parallele (parallel, analogy); — Relazioni strutturali — aggregazione (contains, part_of). Ogni relazione deve usare una voce del vocabolario — il testo libero è vietato (F04–2). Le relazioni di aggregazione usano contains (padre → figlio) e part_of (figlio → padre). Le relazioni possono collegare chunk non adiacenti (F04–4). e interpretazioni devono essere ancorate al chunk a cui si riferiscono tramite una relazione esplicita (F04–5).

5.3.9 Gestione dei gap

Quando un’informazione richiesta è assente, TMSM non si limita a segnare un campo come vuoto: crea un gap chunk esplicito. Un gap chunk deve includere:

• epistemic_status: "missing"; - type: il tipo di chunk atteso;
• time: posizionato nella sequenza temporale dove cade la lacuna;
• gap_reason: spiegazione dell'assenza
• tutti gli altri campi obbligatori, se pertinenti I gap chunk partecipano alle relazioni come qualsiasi altro chunk (es. un gap può avere una relazione temporal.after con l'evento precedente noto).

5.3.10 Rilevamento dei conflitti

Se più fonti producono valori incompatibili per lo stesso campo, tutti i valori in competizione vengono preservati; viene generato un oggetto conflitto con riferimenti al chunk, al campo e ai valori concorrenti, ciascuno con la propria provenienza. TMSM non risolve i conflitti fattuali autonomamente — li segnala e passa la decisione all’operatore.

5.3.11 Validazione

Dopo aver prodotto tutti i chunk, le relazioni e il registro attori, TMSM esegue i test di validazione presenti nella cartuccia: scorre tutti i VALIDATION_TESTS; per ogni test, applica il test_criterion all'output prodotto; registra un verdetto: pass o fail. Se un qualsiasi test su un asse mandatory fallisce, l’output viene marcato come non conforme e vengono segnalati i test falliti. Non è consentito eseguire solo un sottoinsieme dei test o ometterne alcuni. L’intera suite di test deve essere processata e i risultati riportati nella sezione VALIDATION_RESULTS dell’output finale. Questo garantisce che la conformità alla cartuccia sia verificata in modo completo e riproducibile.

5.3.12 Assemblaggio dell’output

L’output finale è assemblato in una struttura ATON con sei blocchi:

• IDENTITY { … }
• ACTOR_REGISTRY [ … ]
• CHUNKS [ … ]
• RELATIONS [ … ]
• CONFLICTS [ … ]
• VALIDATION_RESULTS [ … ] Tutti i riferimenti tra sezioni usano id. Gli attori sono referenziati tramite id del registro, mai con testo libero. I gap chunk sono inclusi in CHUNKS con epistemic_status: "missing".

5.4 Determinismo e tracciabilità

TMSM è progettato per essere deterministico: a parità di materiale grezzo e di cartuccia, deve produrre un output strutturalmente identico. Nessuna variazione stocastica è ammessa nel processo di strutturazione. Inoltre, dove disponibile, TMSM conserva la provenienza delle informazioni, collegando ogni elemento strutturato alla sua fonte originale.

5.5 Cosa TMSM non fa

È importante sottolineare ciò che TMSM non fa: — non inventa fatti (se un’informazione manca, crea un gap chunk); — non altera la struttura della cartuccia; — non produce riassunti narrativi; — non risolve silenziosamente le contraddizioni; — non omette campi obbligatori senza dichiarare gap; — non usa tipi di relazione in testo libero; — non referenzia attori per nome invece che tramite id registro; — non salta il passo di validazione.

5.6 Nel nostro esperimento

Per la cronaca medievale, TMSM ha ricevuto la cartuccia CMSTR-SRC-VILLANI-CRONICA-005, che definisce nei minimi dettagli come devono essere organizzati i materiali: chunk atomici per eventi, chunk aggregati per quadri di stato, campo children obbligatorio, tempo e attori sempre presenti, statuto epistemico esplicito, relazioni con vocabolario controllato, gap rappresentati come chunk, e una serie di test di validazione da superare. Applicando questa cartuccia ai testi grezzi — le fonti sulla cronaca — TMSM ha prodotto una materia prima ordinata: un insieme strutturato di chunk, un registro attori con id stabili, relazioni esplicite tra gli eventi, gap segnalati dove le fonti tacevano, e un report di validazione che attesta la conformità dell’output. Questa materia prima ordinata è ciò che verrà passata al quarto e ultimo agente, TMTC, che dovrà finalmente scrivere il testo della cronaca applicando anche le cartucce di stile e di struttura del testo.

5.7 Struttura dell’output: i sei blocchi ATON

L’output prodotto da TMSM è un artefatto in formato ATON composto da sei blocchi di primo livello. Questa struttura è stabile e indipendente dal contenuto specifico; viene consumata direttamente da TMTC.

• IDENTITY — contiene metadati dell’output: identificatore, versione, data, riferimento alla cartuccia utilizzata, e altre informazioni di contesto.
• ACTOR_REGISTRY — elenco degli attori identificati nei materiali, con la struttura definita dalla cartuccia (id, name, type, attributi opzionali). Questo registro è condiviso: tutti i riferimenti ad attori nei chunk utilizzano gli id definiti qui.
• CHUNKS — collezione dei chunk strutturati, inclusi i chunk di gap (epistemic_status: "missing"). Ogni chunk è un oggetto con i campi obbligatori (id, type, level, children, time, actors, place, epistemic_status, role, confidence) più eventuali campi aggiuntivi dipendenti dal tipo. I chunk atomici hanno children: []; i chunk aggregati hanno children popolato con gli id dei figli.
• RELATIONS — collezione delle relazioni tra chunk. Ogni relazione è un oggetto con campi source, target, type (e subtype se pertinente). I tipi e sottotipi sono esclusivamente quelli definiti nel vocabolario controllato della cartuccia.
• CONFLICTS — collezione degli oggetti conflitto generati quando più fonti forniscono valori incompatibili per lo stesso campo. Ogni conflitto specifica il chunk interessato, il campo, e i valori in competizione, ciascuno con la propria provenienza.
• VALIDATION_RESULTS — risultati dell’esecuzione di tutti i test della cartuccia. Ogni voce riporta l’identificatore del test, il verdetto (pass/fail) e, opzionalmente, una nota esplicativa. Tutti i riferimenti tra blocchi (chunk che riferiscono attori, relazioni che riferiscono chunk) utilizzano esplicitamente gli id definiti nei rispettivi blocchi. In particolare, gli attori sono sempre referenziati tramite id del registro, mai con testo libero. Questa struttura garantisce la piena tracciabilità e interoperabilità con TMTC.

6 Come preparare i testi di partenza

Prima che gli agenti possano lavorare, c’è un problema pratico da risolvere: i testi di riferimento sono spesso opere molto lunghe — intere cronache, enciclopedie, romanzi. Sottoporle integralmente agli agenti non è necessario e nemmeno utile: un’opera lunga raramente è uniforme al 100%, ma la sua coerenza si manifesta come pattern ricorrenti e variazioni controllate. Per catturarli serve un campione rappresentativo, non l’opera completa. Abbiamo quindi messo a punto una procedura sistematica in quattro fasi per selezionare da qualsiasi testo di partenza un estratto di dimensioni contenute (30–100 pagine) che contenga tutte le evidenze necessarie per gli agenti.

• Analisi preliminare. Prima di estrarre pagine, si raccolgono informazioni sull’architettura generale: struttura macroscopica (parti, capitoli, sezioni), varietà interna evidente (alternanza di generi, cambi di voce narrante), materiali di corredo (prefazioni, indici, appendici). L’indice è la mappa più importante.
• Campionamento per lo stile. L’agente di stile (CMSTY) ha bisogno di vedere la prosa nella sua continuità. Si prelevano blocchi consecutivi di 5–10 pagine da almeno quattro punti: inizio (voce di base), metà (variazioni), fine (toni conclusivi), più un punto di svolta e un capitolo tipico. Se l’opera alterna tipi di testo (narrativo, epistolare, saggistico) o voci narranti diverse, si preleva almeno un esempio per ciascuno.
• Campionamento per la struttura. L’agente di struttura (CMSTR) ha bisogno di vedere l’architettura. Si prelevano: l’indice completo, un capitolo iniziale intero, uno centrale, uno finale, uno con apparati (note, rimandi), e uno atipico se esiste. Se ci sono più livelli gerarchici o tipi di unità diversi, si preleva almeno un esempio per livello/tipo.
• Sintesi in un unico documento. Tutti i blocchi selezionati vengono raccolti in un unico file Markdown con: informazioni generali sull’opera, indice, per ogni campione posizione e tipo, e il testo stesso. Questo documento diventa l’input per CMSTY e CMSTR. Nel nostro caso, applicando questa procedura alle Croniche di Villani, abbiamo ottenuto una trentina di pagine — indice, capitoli iniziali, centrali, finali e una digressione — sufficienti a estrarre tutte le regole di stile e struttura.

7 Agente 4 — TMTC: lo scrittore finale

Il quarto e ultimo agente si chiama TMTC — Text Creator. È il terminale della pipeline, l’unico che produce output destinato a lettori umani. Il suo compito è ricevere tutto il materiale preparato dagli agenti precedenti e scrivere il testo finale. A differenza degli altri agenti, TMTC non lavora su un solo input, ma deve integrare tre fonti contemporaneamente:

• La materia prima ordinata prodotta da TMSM: chunk strutturati, registro attori, relazioni, gap, conflitti;
• La cartuccia di struttura del testo prodotta da CMSTR: come organizzare l’informazione;
• La cartuccia di stile prodotta da CMSTY: come scrivere. Il suo compito è soddisfare simultaneamente tre sistemi di vincoli indipendenti — contenuto, struttura, stile — senza violarne nessuno. TMTC opera in due modalità sequenziali: PLAN e COMPOSE. In modalità PLAN, costruisce il Composition Plan — la mappa concreta del testo da scrivere — e lo consegna all’operatore per revisione. In modalità COMPOSE, riceve il piano approvato (eventualmente modificato dall’operatore) e compone la prosa. Tra le due modalità c’è un checkpoint esplicito: l’operatore può ispezionare il piano, riordinare le unità, aggiustare la granularità, cambiare le strategie di trattamento dei gap, aggiungere note — e solo dopo aver autorizzato il passaggio alla modalità COMPOSE, TMTC inizia a scrivere.

7.1 Composizione a tre vincoli

Il principio fondamentale di TMTC è la composizione a tre vincoli (three-constraint composition): contenuto, struttura e stile devono coesistere nel testo finale, con un ordine di precedenza ben definito:

1. Contenuto (priorità assoluta): tutto ciò che viene scritto deve essere tracciabile ai chunk prodotti da TMSM. Niente invenzioni, niente omissioni, niente distorsioni.
2. Struttura (organizzazione): il testo deve rispettare l’architettura definita da CMSTR — sequenza, unità, gerarchia, aperture, chiusure.
3. Stile (espressione): la forma linguistica deve seguire le regole di CMSTY — sintassi, lessico, tono, voce — nei limiti consentiti da contenuto e struttura.

Quando i vincoli entrano in conflitto, la precedenza decide: il contenuto non può mai essere sacrificato per ragioni strutturali o stilistiche; la struttura prevale sullo stile quando sono in gioco scelte organizzative.

7.2 Cosa riceve TMTC

TMTC riceve tre input, tutti in formato ATON:

• Structured materials: l’output di TMSM, con i suoi sei blocchi (IDENTITY, ACTOR_REGISTRY, CHUNKS, RELATIONS, CONFLICTS, VALIDATION_RESULTS);
• Text Structure Cartridge: la cartuccia di struttura del testo prodotta da CMSTR;
• Style Cartridge: la cartuccia di stile prodotta da CMSTY. Prima di procedere, TMTC verifica che i VALIDATION_RESULTS di TMSM non contengano fallimenti su assi mandatory. Se la materia prima non è conforme, si ferma e richiede correzione.

7.3 Il Composition Plan

Il tratto più caratteristico di TMTC è che non inizia a scrivere subito. Prima di produrre una singola frase, costruisce un Composition Plan: un piano esplicito che mappa i chunk in unità compositive, definisce la sequenza, calibra la granularità, assegna strategie di trattamento per gap e conflitti. Il Composition Plan è un artefatto ispezionabile, validabile indipendentemente dalla prosa. È il prodotto della modalità PLAN: una volta costruito e validato contro la cartuccia di struttura, viene consegnato all’operatore. TMTC si ferma e attende. L’operatore esamina il piano — che è, a tutti gli effetti, l’indice concreto del testo che verrà scritto — e può approvarlo così com’è o modificarlo: riordinare le unità, cambiare il livello di granularità, riassegnare le strategie di trattamento per lacune e conflitti, aggiungere note. Solo dopo l’autorizzazione dell’operatore, TMTC passa alla modalità COMPOSE. Se l’operatore ha modificato il piano, TMTC esegue una ri-validazione prima di iniziare a scrivere: verifica che le modifiche introdotte siano compatibili con le cartucce e con i materiali strutturati. Se la ri-validazione fallisce su vincoli obbligatori, la composizione si blocca e la questione viene scalata all’operatore. Questa separazione in due tempi — prima il piano, poi la prosa — non è un tecnicismo. È il punto in cui l’operatore ha il massimo controllo sull’architettura del testo senza dover ancora leggere una riga di prosa. È anche il punto in cui errori di mappatura, squilibri nella granularità o strategie di trattamento inadeguate possono essere corretti a costo zero, prima che la scrittura li renda molto più costosi da modificare. L’algoritmo di costruzione del piano segue nove passaggi deterministici che vedremo nei sottocapitoli: Identificazione dei nuclei; Attrazione dei dipendenti; Formazione delle unità; Sequenziamento; Raggruppamento gerarchico; Calibrazione della granularità; Layout interno; Assegnazione gap e conflitti; Verifica copertura. Questo piano esplicita:

• quali chunk confluiscono in ciascuna unità, con la loro funzione (nucleo, supporto, contesto);
• la granularità assegnata a ogni unità;
• come vengono gestite aperture e chiusure;
• la sequenza completa delle unità;
• l’organizzazione gerarchica (libri, parti);
• eventuali chunk non assegnati (con motivazione);
• le strategie di trattamento per gap e conflitti;
• eventuali ambiguità nella mappatura. Il piano viene validato contro la cartuccia di struttura (modalità PLAN) e consegnato all’operatore insieme a un report di validazione e alle eventuali tensioni rilevate tra le cartucce. Solo dopo l’approvazione dell’operatore — ed eventuale ri-validazione se il piano è stato modificato — TMTC passa alla modalità COMPOSE. In caso di violazioni di vincoli obbligatori, sia nella validazione iniziale sia nella ri-validazione, il piano deve essere rivisto prima di procedere.

7.3.1 Identificazione dei nuclei

Vengono selezionati tutti i chunk con ruolo core. Quelli che condividono lo stesso arco temporale e sono legati da relazioni di aggregazione vengono raggruppati. Ogni gruppo diventa un candidato nucleo per un'unità compositiva.

7.3.2 Attrazione dei dipendenti

Per ogni nucleo, si raccolgono i chunk correlati attraverso il grafo delle relazioni, con un ordine di priorità: aggregazione, causale, esplicativa, contrastiva/parallela, infine solo contiguità temporale. Se un chunk risulta correlato a più nuclei in modo ambiguo (ad esempio, perché ha relazioni causali con due eventi distinti), viene registrato in una lista di ambiguità e, se il chunk è di tipo core, l'agente si rivolge all'operatore.

Quando si raccolgono i chunk correlati a ciascun nucleo, TMTC segue un ordine di priorità basato sul tipo di relazione, dal legame più forte a quello più debole:

1. Aggregazione (contains/part_of) – il legame strutturale più stretto.
2. Causale (cause, effect, enables, prevents) – relazioni di causa-effetto.
3. Esplicativa (explains, justifies, exemplifies) – chiarimenti e dettagli.
4. Contrastiva o parallela (contrast, contradiction, parallel, analogy) – relazioni di opposizione o analogia.
5. Solo contiguità temporale — quando non esistono altre relazioni esplicite, l’adiacenza temporale viene considerata come ultima risorsa.

7.3.3 Formazione delle unità

Ogni nucleo più i suoi dipendenti forma un’unità compositiva. Il tipo dell’unità deriva dal tipo del nucleo: nucleo evento → unità evenemenziale, nucleo stato/aggregato → unità descrittiva.

7.3.4 Sequenziamento

Le unità vengono ordinate in base al campo time dei rispettivi nuclei. Le unità descrittive vengono inserite alla loro posizione temporale. Per eventi contemporanei, l'ordine segue: contesto → causa → evento → effetto → interpretazione.

7.3.5 Raggruppamento gerarchico

Le unità vengono aggregate in contenitori secondo la gerarchia definita dalla cartuccia (libri, parti, capitoli). I confini vengono inferiti da discontinuità temporali, cambi tematici o variazioni di scala. Se i confini non sono inferibili, TMTC scala all’operatore. Quando più unità condividono lo stesso riferimento temporale (ad esempio, eventi che avvengono nello stesso anno), l’ordine interno segue questa sequenza predefinita:

1. Contesto — informazioni di sfondo che inquadrano la situazione.
2. Causa — gli antecedenti o le ragioni dell’evento.
3. Evento — il nucleo informativo principale.
4. Effetto — le conseguenze immediate.
5. Interpretazione — commenti o valutazioni.

Questo schema garantisce coerenza e predicibilità nell’organizzazione testuale, anche quando i dati temporali non consentono una distinzione più fine.

7.3.6 Calibrazione della granularità

A ogni unità viene assegnato un livello di dettaglio: espansa (ricca di supporto), standard (moderata), compressa (minima). La distribuzione deve rispettare T06–1 (almeno due livelli presenti). Nel Composition Plan, a ogni unità compositiva viene assegnato un livello di granularità che determina quanto dettaglio verrà sviluppato nel testo finale. I tre livelli sono: - espansa (expanded) — Nucleo completo, tutto il supporto disponibile, contesto ricco di framing. Utilizzo tipico: più paragrafi, articolazione interna dettagliata. Eventi di particolare rilevanza, nuclei che richiedono approfondimento, unità che fungono da snodo narrativo. - standard — Nucleo completo, supporto essenziale, contesto incluso nell’apertura. Uno o due paragrafi. Utilizzo tipico: la maggior parte delle unità; equilibrio tra informazione e scorrevolezza. - compressa (compressed) — Nucleo conciso, supporto minimo o assente, contesto condensato in una frase. Singolo paragrafo o meno. Utilizzo tipico: eventi marginali, riprese di informazioni già trattate, transizioni rapide. Requisiti: la distribuzione dei livelli deve rispettare T06‑1: almeno due livelli devono essere presenti nel testo (non tutte le unità possono avere la stessa granularità). Inoltre, ogni unità deve essere internamente coerente: all’interno di una stessa unità non si alternano espansioni e compressioni arbitrarie (T06‑2). L’assegnazione viene effettuata durante la costruzione del Composition Plan, sulla base della rilevanza del nucleo (inferita dalle relazioni e dal ruolo) e delle indicazioni della cartuccia di struttura.

7.3.7 Layout interno

Per ogni unità si definisce: apertura (ancoraggio contestuale e temporale), sviluppo del nucleo con supporto subordinato, posizionamento delle interpretazioni (adiacenti al referente), chiusura (conclusione, rinvio, sospensione, continuità implicita).

7.3.8 Assegnazione gap e conflitti

Ogni gap chunk riceve una strategia di trattamento e una posizione in un’unità. Ogni oggetto conflitto riceve una strategia di resa e una posizione. Nel Composition Plan, a ogni chunk di gap e a ogni oggetto conflitto viene assegnata una strategia di resa esplicita, che TMTC applicherà durante la composizione della prosa.

Strategie per i gap informativi (chunk con epistemic_status: "missing"):

• explicit_acknowledgment: il testo riconosce apertamente l’assenza di informazioni. Tipica per chunk di tipo core in unità a granularità espansa. Combina il requisito T08‑1 (esplicitazione dell’incertezza) con lo stile appropriato.
• contextual_note: la lacuna viene menzionata brevemente nel flusso del materiale adiacente, senza interrompere la narrazione. Adatta per chunk di supporto o contesto.
• structural_placeholder: la lacuna occupa una posizione strutturale visibile (ad esempio, un’apertura di unità che dichiara l’assenza). Utilizzata quando la struttura richiede che una certa posizione sia comunque segnalata, anche in assenza di contenuto.

Criteri di selezione suggeriti per i diversi gap: - Chunk core, unità espansa: explicit_acknowledgmen

• Chunk supporto, unità standard: contextual_note
• Chunk core, unità compressa: structural_placeholder
• Chunk contesto, qualsiasi unità: contextual_note

Strategie per i conflitti (oggetti con valori incompatibili):

• present_alternatives: tutte le versioni concorrenti vengono presentate con la loro provenienza. Nessuna versione viene favorita. Utilizza S10 (fonti integrate nella narrazione) e S08 (tono misurato).
• flag_and_defer: il conflitto viene notato, ma la risoluzione viene dichiarata come non disponibile sulla base delle evidenze. Combina T08‑1, S08 e S07. La scelta della strategia viene registrata nel Composition Plan e successivamente applicata in fase di scrittura. In entrambi i casi, TMTC non risolve mai silenziosamente un conflitto: se non viene assegnata alcuna strategia, l’agente escalationa all’operatore. Nel Composition Plan, ogni gap chunk e ogni oggetto conflitto riceve una strategia di trattamento esplicita, che TMTC utilizzerà durante la scrittura.

Trattamento dei gap (lacune informative): - explicit_acknowledgment -Il testo dichiara apertamente l’assenza di informazioni, esplicitando la natura della lacuna (es. “Di quest’anno non si hanno notizie certe...” o “Le fonti tacciono su quanto accadde...”). Uso tipico: Gap di chunk core in unità espansa. - contextual_note -La lacuna viene menzionata brevemente, incastonata nel flusso del materiale adiacente (es. “Dopo l’evento, le tracce si perdono per alcuni anni...”). Uso tipico: Gap di chunk di supporto o contesto in unità standard. - structural_placeholder -La lacuna occupa una posizione strutturale visibile (es. un capitolo o una sezione dedicata a un periodo di cui non si hanno notizie). Uso tipico: Gap di chunk core in unità compressa o quando la struttura lo richiede esplicitamente.

Criteri di selezione: la strategia viene assegnata nel Composition Plan in base al ruolo del chunk (core, support, context) e alla granularità dell’unità (expanded, standard, compressed), seguendo le indicazioni della cartuccia di struttura (T08) e le preferenze dell’operatore.

Trattamento dei conflitti (informazioni contraddittorie) - present_alternatives -Il testo presenta tutte le versioni concorrenti, accompagnate dalla loro provenienza (es. “Secondo una fonte...; secondo un’altra invece...”). Nessuna versione viene privilegiata. Uso tipico: Conflitti tra fonti di pari affidabilità o quando la cartuccia richiede pluralità interpretativa (T08‑2). - flag_and_defer -Il conflitto viene segnalato, ma la risoluzione viene dichiarata come oltre le evidenze disponibili (es. “Non è dato sapere quale delle due versioni corrisponda al vero”). Uso tipico: Conflitti irrisolvibili con le informazioni a disposizione, o quando la cartuccia richiede esplicitazione dell’incertezza senza scelta (T08‑1). In entrambi i casi, TMTC non risolve mai autonomamente il conflitto: se nel Composition Plan non è stata assegnata una strategia (o se la strategia richiede ulteriori decisioni), l’agente escalationa all’operatore. Quando i vincoli di contenuto, struttura e stile entrano in conflitto, TMTC segue una gerarchia chiara con regole di risoluzione specifiche. Il contenuto ha priorità assoluta, seguito dalla struttura che ne definisce l’organizzazione, per finire con lo stile che ne caratterizza l’espressione. Qui di seguito esempi di risoluzione di fronte a vari tipi di conflitto: - Contenuto vs. Struttura — Il contenuto vince. La struttura si adatta (es. se un chunk core non può essere collocato nell’unità prevista, la struttura viene rivista). - Contenuto vs. Stile — Il contenuto vince. Lo stile si adatta (es. se una frase lunga e ipotattica non riesce a veicolare con chiarezza un’informazione incerta, si opta per una costruzione più lineare). - Struttura vs. Stile — Il dominio decide: se il conflitto riguarda l’organizzazione (cosa viene prima, come si apre un’unità), prevale la struttura; se riguarda l’espressione (come formulare una transizione), prevale lo stile. - Entrambi mandatory, genuinamente inconciliabili — La struttura vince. Lo stile si adatta. Il conflitto viene registrato nel report di conflitto tra cartucce. - Mandatory vs. Preferred — Il vincolo mandatory vince, indipendentemente dalla provenienza (struttura o stile).

Esempi concreti: - La struttura richiede un’apertura con ancoraggio temporale (T09‑2). Lo stile richiede frasi lunghe con subordinazione (S01) — Entrambi possono coesistere: una frase lunga che contiene l’ancoraggio temporale.

• La struttura richiede il riconoscimento esplicito di una lacuna (T08‑1). Lo stile richiede tono solenne (S08) — Entrambi: prosa solenne che riconosce la lacuna (es. “Di questo anno le memorie tacciono, né si trova chi ne abbia lasciato ricordo”).
• La struttura richiede che l’interpretazione sia contigua all’evento (T03‑2). Lo stile richiede presenza autoriale minima (S07 debole) — La struttura prevale sulla collocazione; lo stile si adatta con un intervento breve, misurato, che non altera l’equilibrio. Il compromesso viene registrato nel report.
• La struttura richiede molti capitoli brevi (T01). Lo stile richiede paragrafi lunghi e cumulativi (S00) — Si cerca di bilanciare: paragrafi proporzionalmente più brevi ma comunque cumulativi. Se il conflitto è insanabile, viene registrato.

7.3.9 Verifica copertura

Si controlla che ogni chunk appaia in esattamente un’unità o nella lista unmapped_chunks. Nuclei non mappati causano escalation. Il Composition Plan viene poi validato contro la cartuccia di struttura. Se fallisce controlli mandatory, viene rivisto prima di procedere alla scrittura.

7.4 La composizione della prosa

In modalità COMPOSE, con il piano approvato in mano, TMTC inizia a scrivere, unità per unità, seguendo la sequenza stabilita. Per ogni unità: 1 - Apertura: viene reso l’ancoraggio contestuale e temporale definito dal piano, applicando le regole stilistiche di S00 (architettura paragrafo), S01 (architettura frase), S03 (registro), S06 (voce). 2 - Sviluppo del nucleo: il nucleo viene sviluppato con il supporto subordinato secondo T04 e T07, applicando S00, S01, S02, S03, S04. 3 - Resa epistemica:

• chunk factual → affermazione assertiva;
• chunk uncertain → formulazione dubitativa o attenuata (T08, S08);
• chunk missing → riconoscimento esplicito della lacuna secondo la strategia assegnata (gap_treatment). 4 - Resa dei conflitti: se l’unità contiene oggetti conflitto, vengono resi secondo la strategia assegnata:
• present_alternatives: tutte le versioni concorrenti vengono presentate con la loro provenienza;
• flag_and_defer: il conflitto viene notato, la risoluzione dichiarata oltre le evidenze disponibili. 5 - Interpretazione: se presente, viene posizionata adiacente al referente (T03–2), applicando S07, S08, S09. 6 - Chiusura: viene applicata la forma di chiusura definita dal piano, con continuità implicita quando appropriato (T10–2). Dopo ogni unità, TMTC verifica la conformità interna e la continuità con l’unità precedente. Per testi molto lunghi, l’operatore può richiedere checkpoint a intervalli definiti.

7.5 Le validazioni finali

Al termine della composizione, TMTC esegue tre validazioni indipendenti:

Validazione strutturale. Esegue tutti i VALIDATION_TESTS della cartuccia di struttura, applicando i criteri al testo prodotto. Fallimenti su assi mandatory rendono l’output non conforme.

Validazione stilistica. Esegue tutti i VALIDATION_TESTS della cartuccia di stile. Per test quantitativi (lunghezza frasi, densità connettivi, ecc.) applica analisi statistica. Fallimenti su assi strong o moderate-strong rendono l’output non conforme.

Validazione di fedeltà al contenuto. Verifica che:

• ogni chunk core appaia nel testo;
• ogni chunk support dal piano appaia nel testo;
• nessuna affermazione sia priva di chunk di supporto;
• lo statuto epistemico sia fedelmente reso;
• tutti gli oggetti conflitto siano resi, nessuno risolto silenziosamente. La fedeltà al contenuto è sempre vincolante: un fallimento è sempre un errore, indipendentemente da struttura e stile.

7.5.1 Metodi quantitativi per la validazione stilistica

La validazione stilistica non si limita a un giudizio qualitativo, ma applica i test_criterion definiti nella cartuccia di stile utilizzando metriche quantitative quando possibile. Per ogni test, TMTC esegue un’analisi sul testo prodotto e verifica se il criterio è soddisfatto.

Esempi di test con relativi metodi quantitativi di valutazione: - Lunghezza media delle frasi — Calcola il numero di parole per frase, media sul testo o su campioni rappresentativi. Confronta con la soglia definita nel test (es. “media inferiore a 15 parole”). - Frequenza della subordinazione — Identifica le proposizioni subordinate (tramite parser sintattico o pattern) e calcola il rapporto subordinate/frasi totali. Verifica che rientri nell’intervallo previsto. - Densità dei connettivi — Conta i connettivi logici espliciti (quindi, però, perché, ecc.) per paragrafo o per un numero fisso di parole. Confronta con la soglia definita. - Registro lessicale — Verifica la predominanza di termini di un dominio specifico (es. lessico civico) rispetto a un corpus di riferimento, o calcola la frequenza di parole astratte vs concrete. - Presenza autoriale in prima persona — Conta le occorrenze di prima persona singolare per un numero definito di unità o parole. Verifica che rientri nel range previsto (es. “non più di 3 interventi ogni 10 capitoli”). - Tono e retorica — Applica analisi del sentiment o classificazione di polarità per verificare la coerenza con il tono dichiarato (es. solenne, neutro). Per i dispositivi retorici, può utilizzare pattern matching per espressioni caratteristiche.

I test quantitativi sono integrati con valutazioni qualitative quando la misura automatica non è sufficiente (es. per la coerenza della modulazione del registro o per la naturalezza della resa epistemica). I risultati di tutti i test (quantitativi e qualitativi) vengono riportati nel report di validazione, con indicazione esplicita di pass/fail.

Regola di conformità: un fallimento su un test associato a un asse con strength strong o moderate-strong rende l’output non conforme. Per i test su assi con forza inferiore, il fallimento genera un avviso ma non blocca la conformità complessiva, a meno che l’operatore non abbia specificato diversamente.

7.6 L’output finale

Le due modalità producono output distinti.

In modalità PLAN, TMTC produce:

• il Composition Plan: l’intero piano di mappatura, ispezionabile e modificabile dall’operatore;
• il report di validazione del piano: esiti dei controlli strutturali;
• eventuali osservazioni su tensioni tra le cartucce rilevate in fase di pianificazione.

In modalità COMPOSE, TMTC produce:

• il testo in prosa: il prodotto finale, organizzato secondo la gerarchia del Composition Plan;
• il report di validazione: esiti di tutti i test di entrambe le cartucce e della fedeltà al contenuto, con verdetto complessivo (conforme/non conforme);
• eventuale report di conflitto tra cartucce: se durante la composizione sono emerse tensioni irrisolvibili tra struttura e stile.

7.7 Determinismo e variazione lessicale

A differenza di TMSM, TMTC opera nel dominio del linguaggio naturale, che è intrinsecamente non deterministico a livello lessicale: due esecuzioni con gli stessi input possono produrre frasi diverse (sinonimi, ordine delle parole, variazioni sintattiche minori). Tuttavia, TMTC garantisce determinismo strutturale, ovvero l’invariabilità degli aspetti che definiscono l’organizzazione e la fedeltà al contenuto. Gli elementi deterministici (identici a parità di input) sono:

• il Composition Plan: la mappatura chunk → unità, la sequenza, la granularità, le strategie di trattamento per gap e conflitti;
• l’insieme dei chunk resi in ogni unità;
• la resa dello statuto epistemico: factual → assertivo, uncertain → dubitativo/attenuato, missing → riconoscimento esplicito della lacuna;
• gli oggetti conflitto resi e le strategie applicate;
• i risultati delle validazioni (pass/fail sui test). Gli elementi non deterministici (che possono variare tra esecuzioni) sono:
• la realizzazione lessicale: scelta di sinonimi, ordine delle parole, variazioni sintattiche ammesse dallo stile;
• la formulazione specifica di aperture e chiusure, purché rispettino le regole strutturali e stilistiche;
• le sfumature espressive che non alterano né il contenuto né la struttura. Questa distinzione garantisce che il sistema sia riproducibile negli aspetti critici (ciò che viene detto e come è organizzato) lasciando allo stesso tempo la flessibilità necessaria per una prosa naturale e varia.

7.8 Cosa TMTC non fa

Anche in questo caso, è utile chiarire i limiti dell’agente:

• non inventa fatti (se un’informazione manca, la lacuna viene riconosciuta);
• non modifica le cartucce;
• non ristruttura i materiali prodotti da TMSM;
• non decide architettura o stile autonomamente;
• non risolve silenziosamente conflitti presenti nei materiali;
• non omette chunk senza giustificazione tracciabile;
• non garantisce determinismo lessicale (ma solo strutturale);
• non compone prosa senza un Composition Plan approvato dall’operatore.

7.9 Nel nostro esperimento

Per la cronaca medievale, TMTC ha ricevuto:

• la materia prima ordinata prodotta da TMSM (chunk di eventi, registro attori, relazioni temporali e causali, gap dove le fonti tacevano);
• la cartuccia di struttura Chronicle Sequential Event Structure (unità evenemenziali, sequenza cronologica, aperture con data, chiusure con rinvio);
• la cartuccia di stile prosa cronachistica civica (frasi lunghe ipotattiche, lessico concreto, tono solenne, presenza autoriale moderata). In modalità PLAN, il Composition Plan ha mappato ogni evento in un capitolo, aggregato i quadri di stato in unità descrittive, posizionato i gap con esplicito riconoscimento delle lacune documentarie, e assegnato strategie di resa per le (poche) fonti in conflitto. Il piano è stato consegnato per revisione: dopo l’approvazione, TMTC è passato alla modalità COMPOSE. La prosa risultante — una cronaca che copre circa cinquant’anni di vicende cittadine — è stata validata contro entrambe le cartucce e contro i materiali sorgente, risultando conforme su tutti i test obbligatori.

8. Bilancio provvisorio di un esperimento ancora in corso

L’architettura che abbiamo descritto — quattro agenti specializzati, tre cartucce che passano di mano, una separazione netta tra chi definisce lo stile, chi organizza i materiali, chi scrive — è il risultato di un tentativo di rispondere a un problema concreto: l’incapacità di un agente unico di gestire compiti complessi e eterogenei. A percorso ancora aperto, con il sistema non ancora collaudato a sufficienza per trarre conclusioni definitive, possiamo però cominciare a mettere a fuoco alcuni elementi che ci sembrano promettenti, e altrettante domande che restano aperte.

8.1 Cosa abbiamo imparato finora

La separazione delle competenze semplifica la progettazione. Affidare a ciascun agente un compito solo — definire lo stile, definire la struttura, organizzare le fonti, scrivere — ha reso il lavoro di sviluppo molto più lineare di quanto sarebbe stato con un unico sistema monolitico. Ogni agente ha un dominio chiaro, un linguaggio specializzato (gli assi stilistici, gli assi strutturali, il vocabolario controllato delle relazioni) e un set di responsabilità abbastanza circoscritto da poter essere pensato, implementato e testato in relativa autonomia.

Le cartucce rendono esplicite le decisioni. L’idea di rappresentare stile e struttura come oggetti informativi autonomi — le cartucce — ha il vantaggio di rendere visibili e ispezionabili le scelte fatte. Una cartuccia di stile contiene non solo le regole, ma anche la loro provenienza, la forza dell’evidenza che le supporta, i controesempi che ne delimitano il confine, i test che la validano. Lo stesso vale per le cartucce di struttura. Questo significa che si può sempre tornare indietro a vedere perché una certa scelta è stata presa, su quali basi, con quali conferme.

La tracciabilità diventa un vincolo di sistema. Il fatto che ogni agente debba registrare le proprie decisioni — i tratti confermati, quelli rifiutati, le fonti da cui sono stati estratti, le forze di evidenza — non è un ornamento, ma un requisito operativo. Quando TMSM costruisce il registro attori, quando TMTC costruisce il Composition Plan, ogni passaggio lascia tracce. Questo non solo rende il sistema più trasparente, ma permette di diagnosticare errori e ambiguità in modo molto più rapido.

La validazione non è un passo finale, ma un processo diffuso. Ogni agente produce non solo il proprio output, ma anche i test per verificarlo. CMSTY produce test di stile, CMSTR produce test di struttura, TMSM produce un report di validazione che TMTC deve verificare prima di cominciare a pianificare, e TMTC stesso produce una validazione del piano (al termine della modalità PLAN) e una validazione finale su tre livelli (al termine della modalità COMPOSE). Con l’introduzione del checkpoint tra PLAN e COMPOSE, la validazione è diventata ancora più capillare: l’operatore può intervenire sull’architettura del testo prima che venga scritta una sola riga, e se modifica il piano, una ri-validazione automatica garantisce la coerenza delle modifiche con le cartucce. L’idea che la conformità vada controllata a ogni passaggio, e non solo alla fine, ci sembra una delle scelte più solide dell’architettura.

8.2 Quello che ancora non sappiamo

Detto questo, l’esperimento è ancora in una fase che definiremmo prototipale. Abbiamo costruito gli agenti, li abbiamo fatti dialogare tra loro, abbiamo prodotto una cronaca di circa cinquant’anni su un campione limitato di fonti. Ma molte domande restano aperte.

Quanto è generale l’architettura? Il fatto che il sistema sia nato da un caso concreto — la cronaca medievale — non garantisce che si adatti con la stessa efficacia ad altri domini. Abbiamo progettato gli assi stilistici e strutturali pensando a testi in prosa, ma quanto sono universali? Un manuale tecnico, un post sui social, un articolo scientifico, un romanzo richiederebbero forse assi diversi, o una diversa ponderazione. L’architettura è pensata per essere adattabile, ma finché non la testeremo su altri generi non possiamo sapere quanto sia flessibile davvero.

Quanto è robusta la catena? Un sistema multi-agente è forte quanto il suo anello più debole. Se CMSTR produce una cartuccia di struttura con regole ambigue o contraddittorie, TMSM non può fare miracoli. Se TMSM produce una materia prima ordinata con errori di segmentazione, TMTC scriverà testi difettosi. La dipendenza tra gli agenti è lineare: l’errore di uno si propaga a valle. Finora abbiamo lavorato in condizioni controllate, con operatori attenti a verificare ogni passaggio. In uno scenario produttivo, con testi molto più estesi e meno supervisione, la robustezza complessiva dovrà essere dimostrata.

Quanto costa la manutenzione? Gli agenti sono complessi. CMSTY ha un modello a dodici assi, ciascuno con le sue regole di estrazione e conferma. CMSTR ha dodici assi strutturali più sette assi derivati. TMSM ha undici passaggi nel suo flusso di lavoro. TMTC ha un Composition Plan in nove fasi e tre validazioni finali. Tutto questo ha un costo in termini di progettazione, implementazione, debug. La domanda è se la complessità del sistema è giustificata dalla qualità del risultato, o se si potrebbe ottenere altrettanto con un’architettura più semplice. Per ora non abbiamo elementi per rispondere.

Quanto è affidabile la resa epistemica? Uno degli aspetti più delicati è la gestione di incertezze e lacune. TMTC deve rendere i chunk uncertain con formulazioni dubitative, e i gap con riconoscimenti espliciti. Ma quali sono le forme linguistiche appropriate? La cartuccia di stile dà indicazioni generali (tono solenne, lessico concreto, presenza autoriale moderata), ma non prescrive formule specifiche per “segnalare una lacuna documentaria”. Abbiamo fiducia che il modello linguistico sottostante sia in grado di generalizzare a partire dagli esempi, ma è una fiducia ancora da verificare su larga scala.

8.3 Il ruolo dell’umano

In tutto questo, l’operatore umano non è mai uscito di scena. Anzi, la sua presenza è costante e necessaria:

• all’inizio, per selezionare i campioni rappresentativi dai testi lunghi;
• in fase di creazione delle cartucce, per confermare ogni tratto e risolvere ogni contraddizione;
• nel refinement e nella fusione, per scegliere tra alternative;
• tra il piano e la prosa, per ispezionare il Composition Plan e decidere se approvarlo, modificarlo o richiedere una ristrutturazione;
• a valle, per valutare la qualità del testo prodotto e decidere se accettarlo o richiedere revisioni. L’architettura non mira a sostituire l’umano, ma a cambiare il suo ruolo: da scrivano che produce direttamente il testo, a progettista che definisce le regole, a supervisore che verifica i risultati, a decisore che risolve le ambiguità che gli agenti non possono affrontare da soli. In questo senso, il sistema è più un amplificatore di capacità che un sostituto: permette di generare testi strutturati su larga scala partendo da regole esplicite, ma richiede che qualcuno — l’operatore — definisca quelle regole, le validi, e intervenga quando il processo siinceppa.

8.4 Prossimi passi

L’esperimento continuerà su tre fronti:

1. Test su altri domini. Applicheremo la stessa architettura a testi di natura diversa — manuali tecnici, articoli giornalistici, post di blog — per vedere se gli assi reggono e se le cartucce prodotte sono effettivamente riutilizzabili.
2. Raffinamento degli agenti. Alcuni passaggi sono ancora troppo artigianali: la segmentazione dei testi grezzi in TMSM, la costruzione del Composition Plan in TMTC. Cercheremo di renderli più automatici e robusti.
3. Valutazione sistematica della qualità. Dovremo mettere a punto metriche per valutare non solo la conformità alle cartucce (che già abbiamo), ma anche la qualità percepita del testo da parte di lettori umani.

L’ipotesi di partenza — che un agente unico non basti, e che serva un’architettura modulare a cartucce — ci sembra finora confermata dall’esperienza di sviluppo. Ma la vera prova sarà se il sistema riuscirà a produrre testi di qualità comparabile a quelli umani su una scala sufficientemente ampia e con un carico di supervisione accettabile. Per ora, questo è un racconto di lavoro in corso. Torneremo a riferire tra qualche mese, con più dati e, forse, qualche risposta in più.