Nell'agosto 2026, il ricercatore Dmitry V. Alexandrov ha pubblicato su arXiv la prima formalizzazione meccanizzata della Triplet Logic di Romanov, realizzata con il proof assistant Rocq. La scelta anomala arriva subito: prima di costruire uno strumento eseguibile, ha deciso di dimostrare ogni proprietà matematica del sistema. Il risultato porta un'etichetta rara nel software di produzione: verified.
L'idea originale: dimostrare la teoria, poi estrarre lo strumento
La Triplet Logic, abbreviata TLS, è un framework combinatorio fondato sulle triplette. Serve a ragionare su percorsi compatibili dentro strutture stratificate, dette Compact Triplets Structures. Il motore operativo è una procedura di intersezione: la Simple Vertex Intersection.
Alexandrov ha formalizzato il nucleo della teoria dentro Rocq. Ha incluso le Compact Triplets Formulas, le iperstrutture, la procedura di clearing e la SVI stessa.
La logica dietro questa scelta è chiara. Una teoria matematica autonoma merita fondamenta dimostrate, prima di qualunque promessa applicativa. Molti progetti software invertono l'ordine: scrivono il codice, poi cercano garanzie. Qui la sequenza è ribaltata con metodo, e questa inversione definisce l'intera storia. Ribaltare l'ordine ha una conseguenza precisa. Ogni proprietà usata dallo strumento poggia su una dimostrazione già chiusa. Non resta spazio per garanzie assunte a valle. Chi eredita il codice eredita anche le prove.
I risultati verificati
I numeri di questo lavoro hanno un denominatore esplicito. Ogni cifra rimanda a un artefatto pubblico e riproducibile.
Dal paper depositato su arXiv, lo sviluppo in Rocq supera le 23.000 righe di codice distribuite su diciassette file, con 427 tra lemmi e teoremi dimostrati e zero obiettivi ammessi.
- Oltre 23.000 righe di codice Rocq
- 17 file di sviluppo
- 427 lemmi e teoremi dimostrati
- Zero obiettivi ammessi (zero admitted goals)
L'espressione zero admitted goals merita attenzione. In un assistente di prova, un obiettivo ammesso è un passaggio dato per vero, privo di dimostrazione. Un solo obiettivo ammesso incrina la catena intera. Basta un anello non provato per indebolire tutto ciò che gli sta sopra. Azzerarli significa che l'intera catena regge da sola. Nessun teorema si appoggia a una scorciatoia.
Un altro numero riguarda la complessità. Alexandrov dimostra limiti di tempo polinomiali espliciti per le fasi del filtro. Questa garanzia teorica accompagna i benchmark su istanze casuali e strutturate, e le due misure convergono verso il comportamento previsto. La convergenza conta. Il limite dimostrato dice come dovrebbe comportarsi il codice. Il benchmark mostra come si comporta davvero. Quando i due dati coincidono, la teoria non resta sulla carta. La toolchain completa è disponibile come artefatto curato su Zenodo.
Il confine di correttezza: dove la storia diventa istruttiva
Il contributo centrale è un confine di correttezza preciso. Qui la storia guadagna valore reale.
L'esistenza di un insieme che soddisfa il sistema implica che la SVI risulti popolata. L'implicazione inversa, invece, fallisce nel caso generale. Una SVI popolata non garantisce sempre una soluzione valida. Il legame vale in un verso, non nell'altro.
Per le strutture allineate, la doppia implicazione torna completa. Vale anche per sistemi di strutture allineate. In quel perimetro il metodo copre entrambe le direzioni.
C'è di più. Alexandrov formalizza la correttezza della traduzione a finestre raggruppate. Poi mostra un controesempio formale alla sua completezza, e dichiara il limite con la stessa cura usata per i teoremi. Questo è il momento di frizione: un lavoro che indica dove smette di funzionare vale di più di uno che promette copertura totale. La correzione resta il dato più informativo. Chi legge sa in anticipo dove il metodo cede. Questa trasparenza vale più di una garanzia generica, perché elimina la sorpresa in produzione.
Da prova a prototipo: VFR
La teoria dimostrata diventa strumento. Alexandrov estrae VFR, un prototipo in OCaml.
VFR offre due garanzie distinte. Per il frammento sliding-window fornisce una procedura di decisione verificata. Per il 3-CNF generale offre un filtro corretto a un lato.
Un filtro a un lato ha una proprietà utile: quando esclude un'istanza, la sua esclusione è affidabile. Non produce falsi scarti. Quando invece lascia passare un'istanza, il verdetto resta aperto. Conoscere questa asimmetria guida l'uso corretto dello strumento. Il prototipo arriva con un runtime Python e un packaging Docker riproducibile.
La riproducibilità qui è sostanza concreta, oltre la cornice. Chiunque può scaricare l'artefatto, eseguire i benchmark e confrontare i risultati con quelli dichiarati. Il valore di questa scelta emerge nel confronto con la prassi comune: molti strumenti AI arrivano come scatole chiuse, con risultati difficili da replicare. VFR percorre la strada opposta.
Cosa significa "verified" per chi costruisce AI
Il termine verified circola molto nel marketing dell'AI. Questo caso restituisce alla parola il suo peso originario.
Un risultato verificato dichiara tre cose: cosa è stato dimostrato, con quale metodo, entro quale confine. Il lavoro di Alexandrov soddisfa tutti e tre i criteri.
Per un CTO, la lezione è diretta. Una garanzia formale vale quanto il perimetro che dichiara. Un filtro corretto a un lato, con limiti espliciti, è più utile di un modello opaco che promette tutto. Il perimetro dichiarato dice dove contare sullo strumento e dove no. Un modello opaco lascia questa domanda senza risposta, e sposta il rischio sul team che lo integra.
Questa posizione ricorre in molti casi enterprise studiati da questo desk. I risultati che reggono portano sempre un denominatore esplicito, mentre i risultati gonfiati evitano il confronto prima e dopo. Per un board, il segnale riguarda i benchmark del possibile: l'asticella della fiducia si sposta verso l'evidenza controllabile.
What you can take from this
La storia offre un playbook trasferibile, anche fuori dalla logica formale.
Prima lezione: dichiarare il confine di validità aumenta la credibilità. Un risultato con limiti espliciti resiste all'esame esterno.
Seconda lezione: la riproducibilità trasforma un'affermazione in evidenza. Codice, benchmark e packaging aperti permettono a chiunque la verifica.
Terza lezione: la sequenza conta. Dimostrare le fondamenta prima di estrarre lo strumento riduce il rischio a valle. Per una PMI che integra AI, il principio vale identico: definire la metrica, dichiarare il perimetro, rendere il risultato controllabile. Questa disciplina distingue un risultato operativo da una comunicazione.
La domanda aperta
Ogni organizzazione che adotta AI affronta la stessa scelta. Quanta parte dei propri risultati regge a un controllo esterno riproducibile?
Alexandrov ha investito oltre 23.000 righe di prova per rendere la risposta pubblica. La maggior parte dei deployment aziendali resta lontana da questo standard.
La domanda per chi legge è concreta: quale metrica del vostro ultimo progetto AI sopravvive a un audit indipendente, con dato prima e dopo? La risposta indica la distanza tra ciò che annunciate e ciò che potete provare.
Questo articolo è stato redatto da un autore editoriale AI con supervisione umana, in conformità agli obblighi di trasparenza del Regolamento (UE) 2024/1689 (AI Act, Art. 50). Le fonti sono linkate nel testo.
Article by SAGA
Fonti
- arXiv (arxiv.org)
- VFR: A Verified Filter for Sliding-Window 3-CNF — Research Artifact (zenodo.org)
- About The Rocq Prover (rocq-prover.org)
- anjlab/sat3 — Reference Implementation of Romanov's Polynomial Algorithm for 3-SAT (github.com)