Il verificatore cieco: cosa può vedere il nostro gate anti-fabbricazione

Nel luglio 2026 abbiamo testato il verificatore che protegge la nostra pipeline di conformità multi-step dalle falsificazioni inserendo dati falsi nei suoi input. La maggior parte delle falsificazioni inserite sono passate indenni. Quel risultato sembrava un buco di sicurezza nell'unico componente il cui compito è rilevare le falsificazioni. Non lo era, e la ragione per cui non lo era è una regola di progettazione che ora trattiamo come un principio fondamentale.

Il test di inserimento aveva fornito i suoi dati falsi nel brief di reasoning, l'unico documento che il verificatore è tenuto a trattare come verità decisa, e poi ha contato quanti il verificatore ha segnalato. Misurato in questo modo, il verificatore non avrebbe potuto superare un test di competenza sulla falsificazione. Nel frattempo, la soluzione a cui tutti pensano, cioè far sì che il verificatore segnali qualsiasi fatto della bozza assente dal brief, ha fatto qualcosa di peggio che non rilevare le falsificazioni: contro le bozze pulite ha segnalato 9 su 9 su una famiglia di modelli e 3 su 9 su un'altra. E il contratto ristretto che abbiamo mantenuto ha rilevato, in una corsa di produzione reale, la classe di failure che il suo ambito copre effettivamente: una citazione che la bozza affermava e che l'insieme approvato del brief non conteneva.

Chiamiamo il principio alla base di questo il verificatore cieco: un gate anti-fabbricazione deve essere limitato a ciò che può effettivamente vedere. L'unica estensione che abbiamo misurato giudicava la verità senza accesso alle fonti e segnalava la maggior parte delle bozze pulite senza cogliere nessuna delle falsificazioni che lo hanno motivato. Il controllo di onestà deve essere meccanico, e meccanico significa che la risposta risiede negli input.

Il test che ci ha mentito

La pipeline è Beyond, la nostra modalità di generazione di documenti multi-step. Un modello planner legge il compito e scrive un brief di reasoning. Un modello executor renderizza ogni passaggio pianificato rispetto a quel brief. Un modello verifier giudica ogni bozza del passaggio prima che venga rilasciata all'utente. (Una quarta fase riassume la corsa completata; non fa parte di questa storia.) Le tre fasi di giudizio ricevono input diversi, e questa differenza è il punto centrale di questo post.

Il nostro verifier è deliberatamente cieco. Sia il planner che l'executor vedono il contesto completo: cronologia della conversazione, memorie del workspace, file del workspace, contenuto dei documenti caricati e conoscenza del framework iniettata. Il verifier vede solo due documenti: il brief e la bozza in revisione. Il suo contratto tratta i fatti e i giudizi del brief come decisi, e il suo compito è verificare che la bozza sia rimasta fedele ad essi.

Il test di laboratorio ha violato questa premessa senza accorgersene. Abbiamo inserito manualmente dati falsi in un brief vuoto, eseguito il verifier e contato quante falsificazioni inserite ha segnalato. Ne ha segnalate poche; la maggior parte delle falsificazioni inserite è passata. Abbiamo chiamato il verifier rotto. Quello che l'esperimento ha effettivamente misurato era se il verifier avrebbe messo in dubbio il documento che è tenuto a fidarsi. Si è rifiutato, come progettato.

Nella stessa finestra, una corsa di produzione ha mostrato quello che sembrava il colpo di pistola: un fatto organizzativo nell'output rilasciato che nessun input che abbiamo controllato conteneva. Prima di implementare una correzione, l'abbiamo ritirata noi stessi: il fatto "fabbricato" era in un file caricato che l'executor aveva letto legittimamente. Il fatto era fondato. Il nostro controllo spot, come il verifier, semplicemente non aveva guardato quel file. Un investigatore che non può vedere le fonti non può giudicare nemmeno la fondatezza. Avevamo eseguito lo stesso esperimento rotto su noi stessi che avevamo eseguito sul modello.

La trappola misurata

Quindi ci siamo rivolti al lato della bozza, dove gli input del verifier differiscono effettivamente. La soluzione intuitiva: segnalare qualsiasi affermazione fattuale nella bozza che non appare nel brief. Abbiamo costruito esattamente quella regola e l'abbiamo misurata contro le bozze pulite, bozze che non contenevano affatto falsificazioni, generate dalle famiglie di modelli che la pipeline utilizzava in quel momento. La misurazione e la decisione di respingere la regola sono registrate nel commento di progettazione del contratto distribuito e nella cronologia dei commit; il lavoro è stato svolto e registrato nella sessione di revisione del 2026-07-22:

Regola in test	Bozze pulite segnalate	Bozze generate da
Segnala i fatti della bozza assenti dal brief	9 su 9	GLM 5.2
Segnala i fatti della bozza assenti dal brief	3 su 9	Grok 4.20

Un gate che respinge la maggior parte o tutte le bozze pulite non è un gate; è un fermo. Su GLM 5.2, ogni bozza pulita testata avrebbe almeno scatenato un re-render; cosa avrebbe prodotto poi un secondo verifica fallito (una segnalazione di caveat o un arresto) non l'abbiamo misurato. Il meccanismo è strutturale. Un fatto nella bozza che è assente dal brief non è una prova di falsificazione, perché l'executor è autorizzato, per progettazione, a fondare i fatti su fonti che il verifier non può vedere. Per giudicare "questa affermazione è reale?", un verifier senza accesso alle fonti ha solo le sue convinzioni pregresse, e il lavoro di conformità è il dominio in cui le convinzioni pregresse falliscono in entrambe le direzioni: i fatti veri sono specifici dello spazio di lavoro del cliente, e quelli falsi sono plausibili.

Nota cosa anche la regola estesa non poteva fare: rilevare nessuna falsificazione dal test di inserimento, perché quelle falsificazioni vivevano nel brief, che sia il contratto ristretto che la regola estesa trattano come verità. Per costruzione, l'estensione non ha aggiunto alcun richiamo su quella classe; le nostre misurazioni sulle bozze pulite hanno mostrato invece cosa ha aggiunto. Quella coppia di risultati è ciò che ci ha convinto che il mandato, non il modello, fosse il problema.

Il contratto che è sopravvissuto

Quello che il verifier è autorizzato a giudicare è scritto nel suo prompt distribuito, e il confine è netto. Per passaggio, fa rispettare due contratti e nient'altro:

1. Il contratto del passaggio stesso: la bozza consegna ciò che il titolo e la specifica del contenuto di questo passaggio richiedono. Il contenuto mancante è una violazione solo quando la specifica del passaggio lo richiede.
2. I giudizi e le citazioni del brief come vincoli globali, dove esattamente tre cose sono violazioni:
   • contraddizione: un'affermazione nella bozza che contraddice direttamente un punto del giudizio o la specifica del passaggio,
   • citazione alterata: una citazione del brief riprodotta in modo errato (clausola, articolo o formulazione del requisito sbagliati),
   • citazione o requisito inventato: una citazione o un requisito del framework affermato nella bozza che il brief non contiene.

L'assenza non è mai una violazione dei vincoli globali. Il brief instrada il contenuto tra i passaggi; un passaggio di email stakeholder omette correttamente le citazioni a livello di clausola che appartengono al passaggio di policy. Il verifier non giudica stile, tono, lunghezza o qualità complessiva. Una bozza semplice che è fedele al suo passaggio passa.

Questa forma è stata imposta dalla misurazione, due volte. Prima, una calibrazione live su un ambiente di test interno il 2026-06-11, sulla topologia di lancio il cui verifier era Claude Haiku 4.5 (l'insieme di compiti della sessione non è stato registrato nel log durevole; la rivendicazione durevole è il conteggio delle issue sotto): su 12 issue segnalate dal verifier durante l'uso reale, 2 erano reali e 10 erano segnalazioni troppo letterali su bozze che erano effettivamente fedeli. (Questa metrica conta le issue segnalate, non i rifiuti delle bozze pulite.) Seconda, le misurazioni 9-su-9 e 3-su-9 sulle bozze pulite sopra. Entrambe le misurazioni hanno condannato il mandato più ampio, ciascuna sul proprio asse di falsi positivi; l'ambito ristretto è rimasto puntato sulla classe di failure che conta.

La ristrettezza non è una debolezza. È ciò che mantiene il controllo rispondibile. "Questa bozza contraddice il brief?" è una domanda la cui risposta risiede interamente nei due documenti davanti al verifier; non sono richiesti fatti esterni per risolverla. "Questa affermazione è vera?" non è quel tipo di domanda, e nessuna ingegneria del prompt che abbiamo misurato la trasforma in una di queste.

Cosa invece rileva le falsificazioni

Se il verificatore cieco controlla solo la fedeltà, cosa si frappone tra un utente e un output falsificato? Tre livelli, ciascuno limitato a un controllo che non necessita di fatti oltre i propri input:

Citazioni contro una lista chiusa. Il brief contiene un insieme esplicito di citazioni. Le istruzioni dell'executor dicono: riprodurre le citazioni del brief esattamente come scritte; non omettere, alterare o inventare citazioni del framework. Se un numero di clausola appartiene a una lista finita e nota è controllabile senza vedere alcuna fonte. In un dominio di conformità, quel mondo chiuso è il target giusto: l'output pericoloso non è una parafrasi, è una citazione a testo che l'insieme approvato non autorizza.

Un gate di integrità dove una fonte esiste. Su corse che hanno eseguito ricerche web, la pipeline controlla inoltre gli URL e i prezzi di output rispetto all'insieme di prove approvate, perché lì la verità oggettiva è disponibile e finita.

Tubature fail-closed, con un'eccezione deliberata. Il verdetto del verifier è l'unico output leggibile dalla macchina nella pipeline, un oggetto JSON rigoroso con un booleano pass e una lista di issue che deve corrispondere ad esso. Un verdetto che non può essere analizzato causa un arresto, mai un passaggio. Un verdetto fallito scatena esattamente un re-render con la lista delle issue, poi un re-verifica; un secondo fallimento rilascia il passaggio con una flag di caveat, dopo essere stato ispezionato due volte. Un arresto del verifier o un verdetto non analizzabile ottiene un solo tentativo di retry, poi arresta la corsa, e il passaggio in volo non viene mai rilasciato. L'eccezione conta ed è utile dichiararla esattamente: fail-closed si applica all'ispezione, non alla correttezza. Un passaggio significa che il verifier non ha rilevato alcuna violazione del contratto, che non è una garanzia di verità da parte di un modello imperfetto, e una bozza segnalata due volte fallita non ha passato nulla.

Il rilevamento, in produzione

Il 2026-09-02 abbiamo eseguito una sonda su un singolo compito attraverso la nostra pipeline di produzione sul nostro account a pagamento: un compito che abbiamo scritto noi stessi, senza materiale del cliente caricato. Lo scopo era la prova end-to-end della topologia a quattro ruoli in test quel giorno, che ha eseguito ogni ruolo su GLM 5.3 (sforzo alto sul planner, basso sull'executor, verifier e recap). Il compito: redigere una breve bozza di registro delle attività per la norma ISO/IEC 27001:2022 Annex A, una pagina.

La bozza dell'executor citava le clausole 9.2 e 9.3 della ISO/IEC 27001:2022, le clausole di audit interno e revisione della direzione. Entrambe le clausole esistono nello standard; la citazione è esattamente ciò a cui un documento di conformità dall'aspetto competente fa riferimento. Il problema è contrattuale, non fattuale: l'insieme di citazioni approvate del brief non le conteneva, il che le rende citazioni inventate nel senso del contratto, citazioni affermate nella bozza che il brief non autorizza. Il verifier ha restituito un verdetto di fallimento che nominava l'issue, l'executor ha re-renderizzato portando le citazioni all'interno dell'insieme approvato, e il secondo tentativo è passato. La corsa si è completata in 155 secondi senza caveat e senza troncamento, tutte le chiamate su GLM 5.3.

Due proprietà di quel rilevamento contano più dell'aneddoto. Prima, la classe: il failure che si è effettivamente verificato in produzione era un'estensione della citazione oltre l'insieme approvato, precisamente la violazione che il controllo cieco copre, non un fatto inserito a mano. Seconda, la dimensione del controllo: il verifier ha operato con basso sforzo di reasoning e ha visto due documenti. Nella stessa settimana di valutazione della topologia (2026-09-01: cinque compiti difficili che coprono disciplina di ambito, omissione di pubblico, correttezza delle citazioni, coerenza tra documenti e gestione di prove non verificate; tre prove per compito per braccio; 30 corse totali tra due bracci, GLM 5.3 e un braccio proxy Grok 4.20), il braccio GLM 5.3 del verifier ha restituito un verdetto JSON rigoroso analizzabile in tutte le 15 delle sue corse, con zero arresti. Il giudizio era indipendente: Claude Haiku 4.5, eseguito tramite OpenRouter. Il gate che ha rilevato il failure di produzione è la chiamata di modello più ristretta nella pipeline.

Cosa questo non afferma

Il rilevamento in produzione è un singolo punto dati da una sonda deliberata, non una stima di tasso. Il banco di prova di inserimento era un file interno di lavoro che non abbiamo conservato; ci affidiamo al suo risultato qualitativo (la maggior parte delle falsificazioni inserite sono passate, tasso di rilevamento approssimativamente uno su quattro al momento) ma non lo pubblichiamo come misurazione precisa, perché gli artefatti, le versioni dei modelli e l'insieme di compiti dietro di esso non erano congelati. Il record durevole per il test della regola estesa sono le misurazioni 9-su-9 e 3-su-9 sulle bozze pulite nel commento del contratto distribuito, misurate e registrate il 2026-07-22; il record nomina le famiglie che hanno generato le bozze (GLM 5.2, Grok 4.20) ma non nomina il modello verifier o l'insieme di compiti, quindi attribuiamo solo le bozze, e non abbiamo rieseguito il test su altre famiglie. L'indagine sulla corsa ritirata di luglio precede la nostra attuale disciplina di raccolta delle prove, quindi la descriviamo senza identificatori di corsa o attribuzione del modello. Il rischio residuo è reale e documentato nel repo: su corse senza ricerca web, un fatto organizzativo inventato dall'executor, distinto da una citazione inventata, non ha ancora un gate automatizzato, e non abbiamo misurato quanto spesso accada; risolverlo significherebbe dare al verifier le fonti, una riprogettazione, non una clausola di prompt. Tutto qui è istantanea nel tempo come delle date stampate: contratto e codice al 2026-09-16, sonda 2026-09-02, valutazione 2026-09-01, calibrazione su ambiente di test interno 2026-06-11, misurazione della regola estesa 2026-07-22.

La checklist

Prima di fidarti, estendere o "correggere" un gate di verifica nella tua pipeline di agenti:

1. Decidi cosa il verifier può vedere, e lascia che questo decida cosa può giudicare. Cieco alle fonti significa fedeltà solo: contraddizioni, citazioni alterate, citazioni inventate.
2. L'assenza da un riferimento che il produttore può legittimamente superare non è mai una violazione. Se non puoi provare che il fatto è stato fabbricato piuttosto che fondato su una fonte che non hai passato, non segnalarlo.
3. Rendi l'onestà meccanica ovunque il tuo dominio lo permetta. Citazioni contro una lista chiusa, URL e prezzi contro un insieme di prove approvate: questi sono controllabili dagli input. La verità aperta non lo è.
4. Calibra sulle bozze reali prima di fidarti del gate. Misura la tua quota di falsi positivi prima di estendere il contratto; la nostra era 10 su 12 issue su uso reale (2026-06-11). Progetta il contratto in modo che l'assenza non sia una violazione.
5. Un verdetto che non può essere analizzato deve arrestare il passaggio, mai farlo passare. Mantieni un solo verdetto leggibile dalla macchina e rendi il passaggio booleano coerente con la lista delle issue.
6. Un re-render su un verdetto fallito, poi un re-verifica. Rilascia un passaggio fallito due volte solo con una flag di caveat, dopo due ispezioni. Non rilasciare mai contenuto non ispezionato su alcun percorso, inclusi gli arresti del verifier. Un passaggio significa che non è stata rilevata alcuna violazione del contratto, non che il contenuto è vero.
7. Testa con la classe di failure che il tuo dominio produce effettivamente (per noi, citazioni che vanno oltre l'insieme approvato), non con la classe più facile da simulare (fatti inseriti a mano). E bada a dove li inserisci: un falso scritto nel documento di verità del verifier non testa nulla sulla falsificazione.
8. Quando la tua stessa indagine su una presunta falsificazione dipende da input che non hai controllato, sei tu il verificatore cieco. Ritrai prima, misura dopo.

Un verifier che vede meno non è un gate più debole. I suoi verdetti rimangono controllabili, perché giudica solo il contratto che il produttore ha effettivamente ricevuto.