Trame e regolamenti che girano in-process
Il regolamento non dovrebbe essere un oracolo remoto
Le regole di business vengono di solito presentate come qualcosa di semplice. Un cliente è idoneo o non lo è. Una transazione passa o fallisce. Un preventivo ottiene uno sconto. Un utente può accedere a una risorsa. Poi le regole crescono, arrivano le eccezioni, la conformità chiede prove, e improvvisamente il semplice controllo è diventato un servizio di policy, un interprete, una cache, un lavoro di riconciliazione e una riunione con il fornitore. Meraviglioso. Abbiamo reinventato un semaforo con un piano di abbonamento.
Lattice parte da un'idea meno teatrale: il regolamento dovrebbe essere eseguito dove viene presa la decisione. La pagina attuale di Lattice descrive un componente Rust con licenza Apache 2.0 che compila le regole in anticipo in un artefatto binario mappabile in memoria. La valutazione è un percorso in-process attraverso un albero impacchettato. L'artefatto contiene checksum. Le stesse regole e gli stessi dati sono descritti come produttori della stessa risposta sulle piattaforme supportate. Nessun servizio aggiuntivo deve trovarsi sul percorso di una decisione. Questa è la forma utile.
Questo non è contro la governance. È il contrario. La governance si indebolisce quando le regole vivono lontano dai sistemi che le usano e le spiegazioni devono essere ricostruite in seguito. Un regolamento versionato, compilato, con checksum, caricato in-process e riproducibile dà ai revisori qualcosa di più concreto di "abbiamo chiesto al servizio di policy e ha detto di no". Quella frase potrebbe essere vera. Non basta.
Compila una volta, smetti di interpretare per sempre
La pipeline della pagina è chiara: scrivi, compila, impacchetta, valuta. Le regole e i vincoli vivono accanto al codice sorgente e alla cronologia delle versioni. La compilazione classifica i vincoli e fissa il backend del solver. L'impacchettamento produce un artefatto binario con checksum XXH3-64 su intestazione, contenuto e file. Il caricamento è una syscall, non un parse. La valutazione percorre l'albero impacchettato in-process. Questa sequenza è importante perché trasforma il lavoro a runtime in lavoro a build-time.
Gli interpreti sono comodi finché non si trovano su ogni richiesta. Un servizio di policy remoto è comodo finché il salto di rete non diventa parte del budget di latenza e il servizio diventa un'altra cosa che può essere giù. Un JIT è comodo finché host, versioni o ottimizzatori diversi non diventano parte della spiegazione. Lattice è intenzionalmente meno drammatico. Dice che il regolamento dovrebbe diventare un file che l'applicazione può mappare ed eseguire in modo deterministico. Il percorso della richiesta non dovrebbe riscoprire le regole ogni volta.
La pagina riporta numeri di benchmark per il percorso attuale dell'artefatto, inclusi un numero di valutazione a caldo, una ricerca a freddo dopo mmap e cifre di throughput. Quei numeri appartengono alla pagina e al suo contesto di benchmark, non a un mito da copiare in ogni futura release. Il punto ingegneristico duraturo è il design: un artefatto impacchettato, valutazione cache-local, nessun parser sul percorso critico, nessun allocatore sul percorso critico e nessun salto di rete per decisione.
Una singola API per le regole non dovrebbe nascondere la realtà del solver
Le regole non sono tutte uguali. Alcune sono controlli booleani puri. Alcune combinano logica e aritmetica. Alcune sono programmi lineari. Alcune richiedono decisioni intere. Alcune sono vincoli a dominio finito. Alcune sono problemi di percorso o vincoli soft. Un motore di regole serio non dovrebbe forzare ogni caso attraverso un unico buco della serratura a forma di solver. Dovrebbe classificare la regola e instradarla al backend giusto.
La pagina di Lattice riunisce SAT, SMT, LP, MIP, CP, A* e MaxSAT sotto un'unica API di regole. SAT copre le regole booleane pure e i gate di funzionalità. SMT gestisce teorie miste come logica, aritmetica, array e bitvector. LP copre l'ottimizzazione continua. MIP o ILP gestisce le decisioni intere. CP gestisce i domini finiti e i vincoli non lineari. A* e MaxSAT coprono i problemi di percorso e di vincoli soft. La frase di prodotto importante è che chi chiama scrive regole, non chiamate al solver.
Questo conta per la manutenibilità. Se ogni team di prodotto scrive codice di integrazione specifico per il solver, il livello delle policy diventa una raccolta di astuzie locali. Le astuzie locali costano care negli audit perché nessuno ricorda quale era astuta e quale era solo un ripiego del venerdì. Una superficie di regole classificata dà ai team un unico punto in cui ispezionare la regola, la classe di backend, l'artefatto compilato e la risposta prodotta.
La latenza è anche una regola di business
I sistemi decisionali amano fingere che la latenza sia un ripensamento tecnico. Non lo è. Se un controllo di conformità si trova su ogni transazione, la latenza fa parte del prodotto. Se il controllo degli accessi sta su un gateway, la latenza fa parte della sicurezza. Se i prezzi vengono calcolati al momento del preventivo, la latenza fa parte dei ricavi. Se lo screening antifrode avviene prima del regolamento, la latenza fa parte del rischio. Una regola lenta può essere corretta e comunque operativamente sbagliata.
Ecco perché la valutazione in-process conta. La pagina attuale di Lattice contrappone i controlli interpretati o remoti su scala di millisecondi al percorso dell'artefatto impacchettato, e segnala il costo dei salti di rete, dei servizi sidecar e dei vuoti di audit. Il numero esatto di un benchmark conta meno della forma del costo. Se una richiesta richiede dieci controlli, forse il vecchio percorso regge. Se una richiesta richiede diecimila controlli, il vecchio percorso inizia a occupare spazio nel budget della richiesta. A quel punto il motore di regole non è più un componente. È ciò per cui gli utenti aspettano.
Il beneficio operativo non è solo la velocità. Sono meno parti in movimento. Nessun servizio di policy aggiuntivo. Nessun percorso di rete da mantenere in salute. Nessun processo parser separato. Nessuna cache separata da spiegare. Il regolamento sta con l'applicazione, dentro il confine giurisdizionale e operativo che già controlli. È meno affascinante di una dashboard. Ma è anche meno probabile che svegli qualcuno nel cuore della notte.
La risposta per l'audit è il replay
Quando un revisore chiede perché una decisione è stata negata, la risposta peggiore è un paragrafo ricostruito a memoria. La seconda peggiore è uno screenshot. La risposta utile è: questa versione del regolamento è stata eseguita su questo input e ha prodotto questo output, ecco il checksum dell'artefatto, ecco la regola, ecco il replay. Lattice è costruito per rendere possibile quella risposta.
La pagina collega Lattice agli obblighi del GDPR sulle decisioni automatizzate, alla trasparenza richiesta dall'AI Act europeo, alla resilienza operativa di DORA e alla garanzia sulla catena di fornitura di NIS2. Queste etichette possono ridursi a semplice materiale pubblicitario se il sistema non è in grado di mostrare nulla di concreto. La parte concreta è l'artefatto. Un rulebook compilato può essere identificato per nome. Un checksum può rilevare manomissioni. Gli input registrati possono riprodurre la decisione. Un output bit-exact significa che il failover non dovrebbe modificare silenziosamente una risposta. L'esecuzione in-process all'interno di sistemi controllati aiuta a evitare il problema del servizio esterno sul percorso decisionale.
Dove si inserisce per prima cosa
Lattice ha più senso nei punti decisionali che si verificano spesso e che richiedono prove in un secondo momento. Controlli di conformità sulle transazioni. Prezzi e idoneità al momento del preventivo. Decisioni di accesso ai gateway. Screening delle frodi prima del regolamento. Verifiche di idoneità nel settore pubblico. Fasi di sottoscrizione assicurativa. Autorizzazioni per i flussi di lavoro interni. Questi sono luoghi in cui un semplice sì o no non basta. Il sistema deve sapere quale versione del sì o del no si è verificata.
Si adatta anche ai luoghi in cui la stessa decisione deve rimanere identica su server diversi. Un failover non dovrebbe modificare un risultato di conformità. Una distribuzione regionale non dovrebbe interpretare una regola in modo diverso perché una versione di una libreria è cambiata. Una riproduzione per audit non dovrebbe richiedere che lo stesso servizio vendor ospitato esista ancora. Il rulebook dovrebbe essere sufficientemente portabile da poter essere eseguito dove l'organizzazione lo controlla, e sufficientemente esplicito da mantenere bassi i costi di migrazione.
È per questo che l'open source conta anche qui. Un motore di regole che partecipa a conformità, accesso, prezzi o frodi non è una dipendenza decorativa. Fa parte del control plane. Se nessuno all'interno dell'organizzazione può ispezionarlo, bloccarlo, testarlo e mantenerlo, allora il rulebook non è davvero loro. È autorità presa in affitto.
Cosa valutare prima di adottarlo
Prima di tutto, identifica i punti decisionali. Non iniziare con una migrazione di piattaforma. Inizia con un rulebook che oggi causa problemi. Con quale frequenza viene eseguito? Cosa protegge? Chi chiede il perché? Cosa succede se il servizio è fuori uso? Quali prove sono disponibili sei mesi dopo?
In secondo luogo, valuta la forma delle regole. I vincoli sono booleani, aritmetici, lineari, interi, a dominio finito, di tipo path o soft? Quale classe di backend dovrebbe gestirli? Se la regola non può spiegare perché instrada verso una famiglia di solver, l'astrazione è troppo magica.
In terzo luogo, valuta la disciplina sugli artefatti. Dove è memorizzata la regola sorgente? Quale build ha prodotto l'artefatto? Quale checksum è stato caricato? Quale versione dell'applicazione lo ha utilizzato? Quali input sono stati registrati? Quale percorso di riproduzione dimostra la risposta? Se la risposta è distribuita su tre sistemi e una persona di nome Jan, il rulebook non è ancora un oggetto di audit. È una tradizione.
La lezione
Lattice è una storia di motore di regole, ma in realtà è una storia di controllo. Compila il rulebook prima della richiesta. Confezionalo in un artefatto che l'applicazione può mappare in memoria. Verifica l'artefatto prima di caricarlo. Instrada i vincoli verso la giusta famiglia di solver. Valuta in-process. Riproduci in seguito con lo stesso input e la stessa versione del rulebook.
Non è affascinante. Bene. Le regole di business non dovrebbero essere affascinanti. Dovrebbero essere noiose, veloci, esplicite e verificabili. I sistemi decisionali importanti di un'azienda non dovrebbero dipendere da oracoli remoti, cicli di parsing e archeologia di audit. Dovrebbero portare i loro rulebook come infrastruttura.
Il rulebook non dovrebbe essere un oracolo remoto. Dovrebbe essere qualcosa che il sistema può eseguire, nominare e riprodurre.