Che cos'è Jev e come si applica: il modello di giudizio di TypeSafe

Jev è il modello di giudizio di TypeSafe, quello che l'azienda chiama il suo modello System One: una AI che non genera testo, ma risponde a domande chiuse e restituisce probabilità. Esiste per risolvere la domanda che compare in quasi tutti i progetti di AI che si inceppano e che quasi mai si formula ad alta voce: chi decide. Non chi scrive il prompt né chi sceglie il modello. Chi decide se questo ticket scala, se questa fattura passa, se questa richiesta prosegue.

Per tre anni la risposta di default è stata chiedere a un modello generativo di restituire un JSON con la decisione dentro e fidarsi che il formato regga. Di solito regge. Quello che non regge è l'audit.

Jev è la proposta opposta, e il nome non è decorativo: System One rimanda al pensiero veloce, quella risposta che una persona con criterio dà in un secondo senza bisogno di deliberare. Invece di prosa restituisce una distribuzione di probabilità sulle opzioni che hai definito in anticipo. La versione vigente è jev-1.13 e la documentazione delle primitive è la fonte di tutto ciò che segue.

Tre forme di risposta, e non una di più

Questa è tutta la superficie del modello. La brevità è voluta.

• Choice: la risposta è una delle opzioni di un insieme noto e senza ordine interno, come la categoria di un ticket. Il codice agisce con un ramo per opzione.
• Score: la risposta è una posizione su uno spettro che puoi descrivere per livelli, come la gravità di un incidente. Il codice agisce con una soglia, un ordinamento o un peso.
• Noul: la risposta è un sì o un no netti, e ciò che conta è la probabilità, non l'etichetta. Il codice agisce con un if.

Le tre restituiscono sempre qualcosa che il tuo codice consuma senza dover interpretare prosa, ed è la proprietà che conta davvero qui, perché elimina d'un colpo tutto lo strato difensivo di lettura, retry e validazione del formato che accompagna qualsiasi integrazione seria con un modello generativo. Un Choice restituisce l'opzione scelta, le probabilità di tutte e una confidenza. Uno Score restituisce la media ponderata dei livelli. Un Noul restituisce un numero tra zero e uno.

La regola di design che ordina tutto il resto sta in una frase: una buona domanda per Jev è una a cui una persona competente risponderebbe in un secondo se avesse davanti il contesto giusto. «Questo messaggio trasmette urgenza?» Va bene. «Analizza questo messaggio e decidi cosa fare», non va bene. La seconda non è una domanda. È un incarico, e va spezzato in domande piccole e ricomposto nel codice.

La differenza rispetto a chiedere la decisione a un LLM

Sta nel dove vive la policy: sembra una sfumatura di architettura, ed è ciò che decide se il sistema potrà essere ripercorso con un audit sei mesi dopo.

Quando chiedi a un modello generativo di classificare e decidere, la regola di business finisce scritta dentro il prompt, mescolata all'istruzione, al formato di output e alle eccezioni aggiunte col tempo. Cambiare una soglia significa allora riscrivere un paragrafo in prosa e rivalutare tutto da zero, senza alcuna garanzia che la modifica non abbia intanto spostato il comportamento di altri tre casi che nessuno stava guardando, e il risultato è che nessuno sa con certezza cosa fa il sistema, perché il sistema è un testo.

La ripartizione di Jev è esplicita: il modello apporta il giudizio, il codice si tiene il controllo di flusso, l'aritmetica e la policy. I pesi e le soglie vivono nel codice. La documentazione insiste su un punto che conviene sottolineare perché contraddice l'istinto di quasi tutti: quando la decisione finale è sbagliata ma ogni singola risposta è corretta, ciò che è sbagliato è la policy, quindi si cambiano i pesi e le domande si lasciano in pace.

C'è un secondo contrasto, meno filosofico e più operativo. Jev non conta. Non somma, e nemmeno confronta date. La documentazione lo dice senza giri di parole e offre il pattern sostitutivo: per contare elementi si lancia un Noul per elemento nella stessa richiesta e si sommano nel codice le risposte che superano la soglia. Chi ha visto un modello generativo fallire un conteggio di sette righe riconoscerà il problema all'istante.

Quattro pattern che coprono quasi tutto

Il primo è il fan-out speculativo. Tutte le domande che condividono lo stesso stato viaggiano in un'unica richiesta, comprese quelle che contano solo su alcuni rami. Vengono risposte in parallelo, quindi chiedere di più aggiunge pochissima latenza e pochissimi token al costo totale della richiesta, e il codice semplicemente ignora le risposte di cui non ha bisogno su quel ramo preciso. Una seconda richiesta si giustifica solo quando la risposta della prima determina quali dati andare a cercare.

Il secondo è il routing per confidenza, ed è quello che più assomiglia a dirigere un team. La risposta dice cosa. La confidenza dice se agire.

Questi sono i valori che la documentazione sulla confidenza dà come punto di partenza, con la consegna esplicita di iniziare conservativi e di calibrarli sui tuoi dati.

Il terzo è lo scoring composito. Un giudizio complesso, di quelli che in una riunione si risolvono dicendo che dipende, si spezza in uno Score per ogni dimensione che pesa davvero nella decisione, ciascuno si normalizza per il suo numero di livelli e poi si combinano con i pesi che fissi nel codice. Quando cambiano le priorità del business, si tocca un peso. Non si riscrive una domanda.

Il quarto è il percorso della tassonomia: un Choice per ogni livello dell'albero, percorso nel codice. A ogni opzione si dà come criterio ciò che pende da lei, così il modello vede cosa c'è sotto ogni ramo prima di sceglierla. E se le probabilità escono vicine, il codice segue più di un ramo alla volta.

Da dove arriva quello stato è una decisione a parte, e ci sono team che la risolvono mettendo Model Context Protocol davanti, perché il contesto arrivi già filtrato dai sistemi che lo possiedono.

Vale la pena dire anche cosa nessuno dei quattro ripara. Se la precisione cala quando crescono i dati di input, il problema è che lo stato porta dettaglio irrilevante e va filtrato prima nel codice. Se una domanda riformulata cambia un errore con un altro, quella domanda sta pesando due proprietà insieme e va spezzata. E lo stato non viene trattato come ostile per default: il testo che mandi può orientare la risposta, quindi i casi avversari si testano prima del deploy.

Cosa cambia per il talento tech che collabora a progetti

Compare una capacità nuova, e non è sapere usare uno strumento. Quella distinzione separa chi viene pagato a ore da chi viene pagato per criterio.

Progettare un programma Jev sono cinque passi, e nessuno si risolve scrivendo prompt più lunghi:

1. Elencare le decisioni che il sistema deve prendere, ognuna come ramo, soglia o ordinamento.
2. Scrivere una domanda atomica per giudizio, e spezzare qualsiasi domanda che pesi due proprietà.
3. Scegliere la primitiva secondo ciò che il codice farà della risposta.
4. Costruire lo stato minimo che risponde a tutte, calcolando nel codice ciò che il codice può calcolare.
5. Comporre le risposte nel codice: rami, pesi e porte di confidenza.

Quella è analisi delle decisioni e design di sistema. È un muscolo di ingegneria, non di scrittura, ed è continuità diretta di ciò che già esige costruire un agente AI dall'inizio alla fine: la differenza è che qui la parte di giudizio smette di stare nascosta dentro un prompt e diventa un pezzo che si può mostrare, misurare e difendere.

La parte più sottovalutata è la valutazione: la documentazione è categorica, si revisionano una o due domande per iterazione, mai di più, perché le probabilità si muovono in modi difficili da anticipare, e nessuna revisione si dà per buona senza dati etichettati alle spalle. Una confidenza più alta, da sola, non dimostra che la domanda sia migliorata. Chi sa montare quel banco di prova, scegliere i casi che discriminano davvero e difendere i risultati davanti a un comitato che chiede del rischio prima che della tecnologia, ha un argomento commerciale che quasi nessuno può ancora sostenere con l'evidenza sul tavolo.

Il mercato italiano dà un'indicazione su dove sta andando questa storia, anche se ancora non nomina Jev: secondo l'analisi di mercato di Shakers, 454 delle 17.816 offerte tech con skills etichettate in Italia nominano LangChain, contro 5.524 che nominano Python (n=28.708 offerte attive, 17.816 con skills etichettate, da giugno a ottobre 2026). L'orchestrazione dei modelli ha già domanda dichiarata e un nome proprio dentro il testo delle offerte, ed è il primo posto in cui una capacità nuova diventa visibile prima che qualcuno le metta un'etichetta formale in un catalogo di ruoli. Il livello di giudizio dentro quell'orchestrazione è il pezzo che ancora non ha etichetta.

Quel numero misura menzioni nel testo delle offerte, non requisiti contrastati uno a uno. E il denominatore onesto è quello delle offerte con skills etichettate, non il corpus intero, perché il resto non ha skills assegnate e contarle gonfierebbe la percentuale.

Cosa cambia per un'azienda

La domanda di comitato smette di essere quale sia il miglior modello. Ne diventa un'altra: quali decisioni stiamo delegando, e con quale soglia. Quella è governance, non acquisti, ed è la conversazione che manca nella maggior parte dei deploy di agenti AI in azienda.

Tre conseguenze pratiche. La policy diventa leggibile, perché le soglie sono nel codice e versionate come qualsiasi altra decisione di ingegneria, così si può rispondere con esattezza, con lo storico davanti, a cosa è stato automatizzato, sotto quale condizione e da quale data esatta. Compare un percorso di uscita progettato e non improvvisato, perché il routing per confidenza obbliga a definire dall'inizio cosa succede quando il modello non è sicuro, ed è esattamente lo scenario che le demo non mostrano mai. E cala il costo del cambiare idea: se domani il business decide che la gravità pesa più dell'urgenza, quello è un peso in una riga di codice.

Vale la pena collocare questo nel problema di fondo. Lo studio di BCG su più di 1.250 aziende misura il gap senza sconti: solo il 5% ottiene valore a scala e il 60% non ottiene valore materiale nonostante un investimento sostanziale (BCG, settembre 2025). Buona parte di quello implementation gap non è un problema di modello. È che nessuno ha definito quale decisione si stava automatizzando, né con quale confidenza minima, né chi risponde quando la risposta è dubbia.

Un modello di giudizio non risolve questo da solo. Obbliga a scriverlo, che è parecchio più di quello che ottiene la maggior parte dei tool, e il pattern si ripete in qualsiasi sistema che arriva in produzione davvero: lo stesso vale per portare un'architettura RAG in produzione, dove la retrieval raramente è il collo di bottiglia e ciò che fallisce è non aver deciso cosa fare con ciò che è stato recuperato.

I limiti, prima che li scopri in produzione

• Non genera testo. Se ti serve una risposta redatta, quello è un altro modello. Jev sta davanti per decidere quale, o dietro per verificare ciò che è uscito.
• Non ragiona a passi. Un problema che richiede di incatenare tre inferenze si spezza in tre domande letterali e si ricuce nel codice.
• Non fa aritmetica, conteggi né confronto di date. Per le date, il pattern documentato è estrarre ogni parte con un Choice su opzioni enumerate, compresa una per il caso in cui non risulta, e assemblare e confrontare nel codice.
• La sua scala non è una magnitudine continua. Uno Score di 1,0 può significare certezza al livello 1 o un pareggio tra i livelli 0 e 2, quindi si leggono le probabilità accanto al numero e il risultato si usa per applicare una soglia o per ordinare, mai per dedurre una quantità.
• Il contesto ha un tetto. Lo stato e tutte le domande condividono 64.000 token, e lo stato più la domanda più lunga devono stare in 32.000.

Tutto questo è descritto per jev-1.13. La documentazione stessa avvisa che diversi di questi limiti cambieranno in versioni successive, quindi la pagina delle irregolarità del modello si rilegge ogni volta che cambia la versione. Non una sola volta all'inizio.

Da dove partire questa settimana

Prendi una decisione che oggi prende una persona in modo ripetitivo, molte volte al giorno e quasi sempre allo stesso modo, e il cui criterio sai descrivere in una sola frase senza dover ricorrere a uno schema né a un'eccezione che conosce solo chi porta cinque anni nel team. Mettila per iscritto come domanda chiusa. Scegli la primitiva secondo ciò che il tuo codice farà della risposta, che è il criterio di selezione e non l'eleganza del formato. Raccogli trenta casi già risolti con la loro risposta corretta, passali e guarda le probabilità degli errori.

Se il modello sbaglia con confidenza alta, quasi sempre ha letto la tua istruzione in modo strettamente letterale, attenendosi a ogni parola che hai scritto e a nessuna di quelle che davi per scontate, mentre intendevi dire qualcosa di leggermente diverso che non hai mai scritto. La spiegazione che daresti vedendo quell'errore è, letteralmente, la metà che mancava dell'istruzione. Mettila dentro.

Domande frequenti su Jev

Jev sostituisce un LLM generativo?

No. Copre una funzione diversa: decidere tra opzioni che definisci tu, non produrre testo. L'abitudine è combinarli, con Jev che classifica e decide la rotta davanti, e un modello generativo che redige dietro quando serve redigere.

Che cos'è un Noul?

Una delle tre primitive di risposta di Jev. Restituisce un numero tra 0 e 1 per una condizione che ammette un sì o un no netti, e il segnale è la probabilità stessa. Uno 0,5 significa che il modello non è sicuro, non che la risposta sia intermedia. Per misurare un grado si usa uno Score.

Si può auditare una decisione presa con Jev?

Più di una presa dentro un prompt. Le domande, i criteri di ogni opzione, le soglie e i pesi sono artefatti di codice versionati, e ogni risposta porta con sé la sua distribuzione di probabilità completa.

Quante domande conviene mandare insieme?

Tutte quelle che condividono lo stesso stato, in una sola richiesta, comprese quelle che si usano solo su alcuni rami. Vengono risposte in parallelo, quindi chiedere di più aggiunge poca latenza e pochi token.

C'è domanda di questo nel mercato italiano?

Del livello di orchestrazione, sì e con nome proprio: 454 delle 17.816 offerte tech con skills etichettate nominano LangChain, secondo l'analisi di mercato di Shakers (n=28.708 attive, da giugno a ottobre 2026). Di Jev in particolare, ancora no: è un modello recente e nessuna offerta lo nomina.