Lattice și regulamente care rulează în proces
Regulamentul nu ar trebui să fie un oracol îndepărtat
Regulile de business sunt de obicei introduse ca ceva simplu. Un client este eligibil sau nu. O tranzacție trece sau eșuează. O ofertă primește o reducere. Un utilizator poate accesa o resursă. Apoi regulile cresc, apar excepțiile, conformitatea cere dovezi, iar dintr-o dată verificarea simplă a devenit un serviciu de politici, un interpretor, un cache, un job de reconciliere și o întâlnire cu furnizorul. Minunat. Am reinventat un semafor cu un plan de abonament.
Lattice pornește de la o idee mai puțin teatrală: regulamentul ar trebui să ruleze acolo unde se ia decizia. Pagina actuală Lattice descrie o componentă Rust sub licență Apache 2.0 care compilează regulile din timp într-un artefact binar mapabil în memorie. Evaluarea este o parcurgere a arborelui împachetat, în proces. Artefactul poartă sume de control. Aceleași reguli și aceleași date sunt descrise ca producând același răspuns pe platformele suportate. Niciun serviciu suplimentar nu trebuie să stea pe calea unei decizii. Aceasta este forma utilă.
Acesta nu este anti-guvernanță. Este exact opusul. Guvernanța slăbește când regulile trăiesc departe de sistemele care le folosesc, iar explicațiile trebuie reconstruite ulterior. Un regulament versionat, compilat, cu sumă de control, încărcat în proces și reproductibil oferă auditorilor ceva mai concret decât „am întrebat serviciul de politici și a spus nu”. Propoziția aceea poate fi adevărată. Nu este suficient.
Compilează o dată, nu mai interpreta niciodată
Pipeline-ul paginii este clar: autorizează, compilează, împachetează, evaluează. Regulile și constrângerile stau lângă codul sursă și istoricul versiunilor. Compilarea clasifică constrângerile și fixează backend-ul solverului. Împachetarea produce un artefact binar cu sume de control XXH3-64 peste antet, conținut și fișier. Încărcarea este un apel de sistem, nu o parsare. Evaluarea parcurge arborele împachetat în proces. Această secvență contează pentru că transformă munca din timpul rulării în muncă din timpul construirii.
Interpretorii sunt convenabili până când stau pe fiecare cerere. Un serviciu de politici la distanță este convenabil până când saltul de rețea devine parte din bugetul de latență, iar serviciul devine un alt lucru care poate pica. Un JIT este convenabil până când gazdele, versiunile sau optimizatoarele diferite devin parte din explicație. Lattice este intenționat mai puțin dramatic. Spune că regulamentul ar trebui să devină un fișier pe care aplicația îl poate mapa și executa determinist. Calea cererii nu ar trebui să redescopere regulile de fiecare dată.
Pagina raportează numere de referință pentru calea actuală a artefactului, inclusiv un număr pentru evaluare la cald, o căutare la rece după mmap și cifre de debit. Aceste numere aparțin paginii și contextului său de referință, nu unui mit care ar trebui copiat în fiecare versiune viitoare. Punctul de inginerie durabil este designul: un artefact împachetat, evaluare locală în cache, fără parser pe calea critică, fără alocator pe calea critică și fără salt de rețea per decizie.
O singură API de reguli nu ar trebui să ascundă realitatea solverului
Regulile nu sunt toate la fel. Unele sunt verificări booleene pure. Altele combină logică cu aritmetică. Unele sunt programe liniare. Unele necesită decizii cu numere întregi. Unele sunt constrângeri cu domenii finite. Unele sunt probleme de drum sau constrângeri flexibile. Un motor de reguli serios nu ar trebui să forțeze fiecare caz printr-un singur gaura de cheie în formă de solver. Ar trebui să clasifice regula și să o ruteze către backend-ul potrivit.
Pagina Lattice grupează SAT, SMT, LP, MIP, CP, A* și MaxSAT sub o singură API de reguli. SAT acoperă reguli booleene pure și feature gates. SMT gestionează teorii mixte, precum logică, aritmetică, tablouri și bitvectors. LP acoperă optimizarea continuă. MIP sau ILP gestionează decizii cu variabile întregi. CP gestionează domenii finite și constrângeri neliniare. A* și MaxSAT acoperă probleme de drum și constrângeri soft. Mesajul important al produsului este că apelantul scrie reguli, nu apeluri către solver.
Asta contează pentru mentenanță. Dacă fiecare echipă de produs scrie cod de integrare specific solverului, stratul de politici devine o colecție de trucuri locale ingenioase. Trucurile locale ingenioase sunt costisitoare în audituri, pentru că nimeni nu-și amintește care truc a fost ingenios și care a fost doar o improvizație de vineri. O suprafață de reguli clasificată oferă echipelor un singur loc unde pot inspecta regula, clasa de backend, artefactul compilat și răspunsul produs.
Latența este și ea o regulă de business
Sistemele de decizie adoră să pretindă că latența este o considerație tehnică secundară. Nu este. Dacă o verificare de conformitate stă pe fiecare tranzacție, latența face parte din produs. Dacă controlul accesului stă la un gateway, latența face parte din securitate. Dacă prețurile se calculează la momentul ofertei, latența face parte din venituri. Dacă screeningul de fraudă rulează înainte de decontare, latența face parte din risc. O regulă lentă poate fi corectă și totuși greșită din punct de vedere operațional.
De aceea contează evaluarea în proces. Pagina actuală Lattice contrastează verificările interpretate sau remote la scară de milisecunde cu calea artefactului împachetat și evidențiază costul hopurilor de rețea, al serviciilor sidecar și al lacunelor de audit. Numărul exact pentru un benchmark este mai puțin important decât forma costului. Dacă o cerere necesită zece verificări, poate că vechea cale supraviețuiește. Dacă o cerere necesită zece mii de verificări, vechea cale începe să ocupe loc în bugetul cererii. În acel moment, motorul de reguli nu mai este o componentă. Este lucrul pentru care utilizatorii așteaptă.
Beneficiul operațional nu este doar viteza. Este vorba de mai puține piese în mișcare. Fără serviciu de politici suplimentar. Fără cale de rețea de menținut sănătoasă. Fără proces de parsare separat. Fără cache separat de explicat. Regulamentul stă alături de aplicație, în interiorul jurisdicției și al limitei operaționale pe care deja o controlezi. Asta este mai puțin spectaculos decât un dashboard. Dar este și mai puțin probabil să trezească pe cineva din somn.
Răspunsul pentru audit este replay-ul
Când un auditor întreabă de ce o decizie a fost respinsă, cel mai prost răspuns este un paragraf reconstruit din memorie. Al doilea cel mai prost răspuns este o captură de ecran. Răspunsul util este: această versiune de regulament a rulat pe acest input și a produs acest output, iată checksum-ul artefactului, iată regula, iată replay-ul. Lattice este construit în jurul posibilității de a oferi acest răspuns.
Pagina leagă Lattice de deciziile automate conform GDPR, transparența din EU AI Act, reziliența operațională din DORA și asigurarea lanțului de aprovizionare din NIS2. Aceste etichete pot rămâne doar praf de marketing dacă sistemul nu poate arăta nimic concret. Partea concretă este artefactul. Un set de reguli compilat poate fi denumit. Un checksum poate respinge manipulările. Intrările înregistrate pot reda decizia. Ieșirea identică la nivel de bit înseamnă că un failover nu ar trebui să schimbe pe tăcute un răspuns. Rularea în proces, în interiorul sistemelor controlate, ajută la evitarea problemei serviciului extern pe calea deciziei.
Unde se potrivește mai întâi
Lattice are cel mai mult sens la punctele de decizie care apar frecvent și care trebuie să poată fi dovedite ulterior. Verificări de conformitate pe tranzacții. Prețuri și eligibilitate la momentul ofertei. Decizii de acces la gateway-uri. Screening antifraudă înainte de decontare. Verificări de eligibilitate în sectorul public. Porți de subscriere în asigurări. Permisiuni interne pentru fluxurile de lucru. Acestea sunt locuri în care da sau nu nu este suficient. Sistemul trebuie să știe care versiune de da sau nu a avut loc.
Se potrivește și în locurile în care aceeași decizie trebuie să rămână aceeași pe mai multe servere. Un failover nu ar trebui să schimbe un rezultat de conformitate. O implementare regională nu ar trebui să interpreteze o regulă diferit pentru că o versiune de bibliotecă a deviat. O redare pentru audit nu ar trebui să depindă de existența aceluiași serviciu găzduit de un furnizor. Setul de reguli ar trebui să fie suficient de portabil pentru a rula acolo unde organizația îl controlează și suficient de explicit pentru ca costurile de schimbare să rămână scăzute.
De aceea open source contează și aici. Un motor de reguli care participă la conformitate, acces, prețuri sau fraudă nu este o dependență decorativă. Face parte din planul de control. Dacă nimeni din organizație nu îl poate inspecta, fixa, testa și menține, atunci setul de reguli nu este cu adevărat al lor. Este autoritate închiriată.
Ce să verifici înainte de adopție
În primul rând, identifică punctele de decizie. Nu începe cu o migrare de platformă. Începe cu un set de reguli care doare astăzi. Cât de des rulează? Ce protejează? Cine întreabă de ce? Ce se întâmplă dacă serviciul este indisponibil? Ce dovezi sunt disponibile șase luni mai târziu?
În al doilea rând, verifică forma regulilor. Constrângerile sunt booleene, aritmetice, liniare, întregi, cu domeniu finit, de tip cale sau soft? Ce clasă de backend ar trebui să le gestioneze? Dacă regula nu poate explica de ce se îndreaptă către o familie de solvere, abstracția este prea magică.
În al treilea rând, verifică disciplina artefactului. Unde este stocată regula sursă? Ce build a produs artefactul? Ce checksum a fost încărcat? Ce versiune de aplicație l-a folosit? Ce intrări au fost înregistrate? Ce cale de redare demonstrează răspunsul? Dacă răspunsul este împrăștiat pe trei sisteme și o persoană pe nume Jan, setul de reguli nu este încă un obiect de audit. Este o tradiție.
Lecția
Lattice este o poveste despre un motor de reguli, dar de fapt este o poveste despre control. Compilează setul de reguli înainte de cerere. Împachetează-l într-un artefact pe care aplicația îl poate mapa în memorie. Verifică artefactul înainte de încărcare. Direcționează constrângerile către familia potrivită de solvere. Evaluează în proces. Redă mai târziu cu aceeași intrare și aceeași versiune a setului de reguli.
Nu este ceva spectaculos. Bine. Regulile de business nu ar trebui să fie spectaculoase. Ar trebui să fie plictisitoare, rapide, explicite și ușor de revizuit. Sistemele importante de decizie dintr-o companie nu ar trebui să depindă de oracole remote, bucle de parsare și arheologie de audit. Ar trebui să își poarte seturile de reguli ca pe infrastructură.
Setul de reguli nu ar trebui să fie un oracol remote. Ar trebui să fie ceva ce sistemul poate rula, denumi și reda.