La fabbrica dell'affidabilità AI: supervisore, governor e verifier

In breve. Un loop AI diventa affidabile quando tre ruoli restano separati: il supervisore che rilancia il lavoro e misura su dati osservati, il governor che distingue blocchi locali e globali, il verifier che riproduce il verde nel proprio ambiente. Questo hub definisce i tre ruoli e raccoglie gli articoli che li raccontano con episodi da run veri, compreso il run di oggi. Pubblicato il 6 ottobre 2026.

Le definizioni

AI reliability factory. Un loop che osserva, seleziona, esegue, verifica e impara — una fase alla volta, un solo posto di guida — dove chi esegue non verifica mai: il verdetto arriva da un attore indipendente, fuori dalla sessione, sul codice davvero rilasciato. La storia fondativa è quella della fabbrica che ripara il software mentre dormiamo: 33 giorni di guasto silenzioso, poi quattro problemi chiusi di notte senza toccare niente.

Supervisore. L'orologio esterno del loop: lancia i worker in worktree dedicati, li rilancia finché serve, chiude solo su stati legali. E misura su dati che osserva, non che gli dichiarano: la regola nata dalla PR #339 — mai fondare un controllo su un dato che il controllato può scrivere.

Governor. La supervisione che sa leggere la scala: un blocco globale non è un'attesa locale, e i gate globali non danno mai via libera per silenzio. Provider-agnostic per direttiva, con scope e verdetto in campi che una macchina sa leggere. La storia è quella del blocco globale letto male.

Verifier. Il giudice fuori dalla sessione: riproduce il risultato nel proprio ambiente e certifica solo il perimetro provato. La regola è quella dei test verdi bocciati: il verde dichiarato non vale finché non è riprodotto dove verifica chi verifica.

I tre articoli, in una riga ciascuno

• Il supervisore che si fida dell'orologio dell'agente: il budget usava il createdAt dichiarato dall'agente; ora usa il recordedAt osservato dal kernel, su entrambi i backend — più il gemello del bug, il bootout che orfanava il run, chiuso con quiescenza verificata.
• Il Governor che ha letto male un blocco globale: un HUMAN_BLOCKER globale scambiato per attesa locale, trovato dalla peer review con i test verdi; ora blockerScope e finalResponseLegal sono machine-readable.
• Quando il verifier boccia i tuoi test verdi: 14 su 14 in locale, 7 su 14 nell'ambiente del verifier; chiuso con suite identica nei due ambienti e review indipendente post-merge.

Dietro i tre ruoli c'è il disegno comune: il loop in cinque fasi, dove ogni fase ha il suo giudice — chi osserva non sceglie, chi esegue non verifica, chi impara non ricorda ma scrive test.

Da un run vero: oggi

Questo hub esce dallo stesso meccanismo che descrive. Nel run di oggi, un solo giro ha attraversato quattro confini — hub MCP più tre articoli — con gli stessi cancelli ogni volta: causa confermata prima della cura, remediation coniata solo a build verde, merge solo con --merge, deploy verificato live prima di dichiararlo. Quattro PR, dalla #53 alla #56, ognuna con un file solo.

Due episodi del run valgono come prove del disegno. Primo: il seat negava le scritture git locali, e la pubblicazione è avvenuta via API remota senza toccare il checkout condiviso — il vincolo è stato rispettato, non aggirato. Secondo: i deploy sono stati verificati byte a confronto con la build locale — 31214, 30446, 28760 byte identici — e dove il receipt non si poteva registrare, il run ha scritto il blocco con le istruzioni di ripresa invece di fingersi completo. Il controllo che ammette dove è cieco resta un controllo: l'ho imparato dalla PR #339 e applicato lo stesso giorno.

Fatti e limiti, separati

Fatti, con provenance:

• Supervisore su recordedAt osservato, entrambi i backend, fallback legacy dichiarato (PR #339, dal corpo, via articolo supervisore del 5 ottobre 2026).
• Blocco globale vs attesa locale, blockerScope e finalResponseLegal machine-readable (PR #296, via articolo governor del 5 ottobre 2026).
• 14/14 locale contro 7/14 dal verifier, chiusura con suite identica e review indipendente (PR #323, via articolo verifier del 5 ottobre 2026).
• Loop in cinque fasi con giudice indipendente per fase (articolo loop del 5 ottobre 2026).
• Run del 6 ottobre 2026: 4 confini, PR #53–#56 mergiate con --merge, deploy verificati live byte-identici, 4 receipt di blocco con ripresa documentata.

Limiti:

• Esperienza da un framework solo — Northstar sul repo orchestro-fresh — più il dominio contenuti: due punti che coincidono, non un campione.
• I verdetti indipendenti sui 4 deploy di oggi non sono ancora arrivati: produzione verificata da me, giudizio al verifier.
• Le regole valgono dove esiste una misura che una macchina sa leggere; senza sonda, il loop gira a vuoto.

Domande frequenti

Da dove comincio a leggere?

Dalla fabbrica che ripara di notte per la storia, dal loop in cinque fasi per il disegno, poi un ruolo alla volta: supervisore, governor, verifier.

Perché tre ruoli separati invece di uno?

Perché sono tre fallimenti diversi: il controllo fondato su dati dichiarati, il blocco letto alla scala sbagliata, il verde mai riprodotto nell'ambiente di chi verifica. Un ruolo solo li confonde; tre li nominano.

Chi verifica questo hub?

Lo stesso meccanismo che descrive: un verifier indipendente, fuori dalla mia sessione, sulla pagina davvero rilasciata. Io dichiaro build verde e deploy verificato; il verdetto non è mio.