Lattice a pravidlá bežiace v procese
Pravidlá by nemali byť vzdialeným orákulom
Biznis pravidlá sa zvyčajne predstavujú ako niečo jednoduché. Zákazník je oprávnený alebo nie. Transakcia prejde alebo zlyhá. Cenová ponuka dostane zľavu. Používateľ môže pristupovať k zdroju. Potom pravidlá rastú, prichádzajú výnimky, compliance žiada o dôkazy, a zrazu sa z jednoduchej kontroly stal policy servis, interpret, cache, reconciliácia a stretnutie s dodávateľom. Skvelé. Znovu sme vynašli semafor s predplatným.
Lattice vychádza z menej divadelnej myšlienky: pravidlá by mali bežať tam, kde sa rozhodnutie prijíma. Aktuálna stránka Lattice popisuje Rust komponent pod licenciou Apache 2.0, ktorý kompiluje pravidlá vopred do binárneho artefaktu mapovateľného do pamäte. Vyhodnotenie je prechod stromom zabaleným v procese. Artefakt nesie kontrolné súčty. Rovnaké pravidlá a rovnaké dáta sú opísané tak, že na podporovaných cieľoch produkujú rovnakú odpoveď. Na ceste rozhodnutia nemusí sedieť žiadna extra služba. Toto je užitočný tvar.
Toto nie je proti governance. Je to presný opak. Governance slabne, keď pravidlá žijú ďaleko od systémov, ktoré ich používajú, a vysvetlenia sa musia rekonštruovať neskôr. Pravidlá, ktoré sú verzované, skompilované, s kontrolnými súčtami, načítané v procese a prehrateľné, dávajú audítorom niečo konkrétnejšie, ako keď sme sa opýtali policy servisu a on povedal nie. Táto veta môže byť pravdivá. Nestačí to.
Kompilujte raz, prestaňte interpretovať navždy
Pipeline stránky je jasný: autor, kompilácia, balenie, vyhodnotenie. Pravidlá a obmedzenia žijú vedľa zdrojového kódu a histórie verzií. Kompilácia klasifikuje obmedzenia a pripne solver backend. Balenie produkuje binárny artefakt s XXH3-64 kontrolnými súčtami nad hlavičkou, obsahom a súborom. Načítanie je syscall, nie parsovanie. Vyhodnotenie prechádza zabaleným stromom v procese. Táto postupnosť je dôležitá, pretože mení prácu za behu na prácu pri build-e.
Interpretry sú pohodlné, kým nesedia na každom requeste. Vzdialený policy servis je pohodlný, kým sa sieťový hop nestane súčasťou rozpočtu latencie a servis sa nestane ďalšou vecou, ktorá môže byť dole. JIT je pohodlný, kým sa rôzne hosty, verzie alebo optimalizátory nestanú súčasťou vysvetlenia. Lattice je zámerne menej dramatický. Hovorí, že pravidlá by sa mali stať súborom, ktorý aplikácia môže mapovať a deterministicky vykonávať. Cesta requestu by nemala zakaždým znovu objavovať pravidlá.
Stránka uvádza benchmark čísla pre aktuálnu artefaktovú cestu, vrátane čísla pre hot evaluation, cold lookup po mmap a priepustnosť. Tieto čísla patria stránke a jej benchmark kontextu, nie mýtu, ktorý by sa mal kopírovať do každého budúceho vydania. Trvalý inžiniersky bod je dizajn: zabalený artefakt, cache-lokálne vyhodnotenie, žiadny parser na kritickej ceste, žiadny alokátor na kritickej ceste a žiadny sieťový hop na rozhodnutie.
Jednotné rule API by nemalo skrývať realitu solverov
Pravidlá nie sú všetky rovnaké. Niektoré sú čisto booleovské kontroly. Niektoré kombinujú logiku s aritmetikou. Niektoré sú lineárne programy. Niektoré potrebujú celočíselné rozhodnutia. Niektoré sú obmedzenia s konečnou doménou. Niektoré sú problémy s cestami alebo mäkké obmedzenia. Seriózny rules engine by nemal tlačiť každý prípad cez jeden solverový kľúčový otvor. Mal by klasifikovať pravidlo a smerovať ho na správny backend.
Stránka Lattice uvádza SAT, SMT, LP, MIP, CP, A* a MaxSAT pod jedno jednotné API pre pravidlá. SAT pokrýva čisto boolovské pravidlá a funkčné brány. SMT zvláda zmiešané teórie, ako sú logika, aritmetika, polia a bitvektory. LP pokrýva spojitú optimalizáciu. MIP alebo ILP zvláda celočíselné rozhodnutia. CP zvláda konečné domény a nelineárne obmedzenia. A* a MaxSAT pokrývajú problémy s cestami a mäkkými obmedzeniami. Dôležitá produktová veta je, že volajúci píše pravidlá, nie volania solverov.
To je dôležité pre udržiavateľnosť. Ak každý produktový tím píše integračný kód špecifický pre solver, vrstva politík sa stane zbierkou dômyselných lokálnych trikov. Dômyselné lokálne triky sú drahé pri auditoch, pretože nikto si nepamätá, ktorý trik bol dômyselný a ktorý bol len piatkový. Klasifikovaný povrch pravidiel dáva tímom jedno miesto, kde si môžu prezrieť pravidlo, jeho triedu backendu, skompilovaný artefakt a odpoveď, ktorú vyprodukoval.
Latencia je tiež obchodné pravidlo
Rozhodovacie systémy radi predstierajú, že latencia je technický detail. Nie je. Ak kontrola súladu sedí na každej transakcii, latencia je súčasťou produktu. Ak kontrola prístupu sedí na bráne, latencia je súčasťou bezpečnosti. Ak sa ceny počítajú v čase cenovej ponuky, latencia je súčasťou výnosov. Ak sa podvodová kontrola spúšťa pred zúčtovaním, latencia je súčasťou rizika. Pomalé pravidlo môže byť správne a napriek tomu prevádzkovo nesprávne.
Preto záleží na vyhodnotení v rámci procesu. Súčasná stránka Lattice porovnáva milisekundové interpretované alebo vzdialené kontroly s cestou zabaleného artefaktu a upozorňuje na náklady sieťových prechodov, vedľajších služieb a medzier v auditoch. Presné číslo pre jeden benchmark je menej dôležité ako tvar nákladov. Ak jedna požiadavka potrebuje desať kontrol, stará cesta možno prežije. Ak jedna požiadavka potrebuje desaťtisíc kontrol, stará cesta začne zaberať miesto v rozpočte požiadavky. V tom bode už engine pravidiel nie je komponent. Je to vec, na ktorú používatelia čakajú.
Prevádzkový prínos nie je len rýchlosť. Je to menej pohyblivých častí. Žiadna extra služba politík. Žiadna sieťová cesta, ktorú treba udržiavať zdravú. Žiadny samostatný proces parsera. Žiadna samostatná vyrovnávacia pamäť, ktorú treba vysvetľovať. Kniha pravidiel sedí s aplikáciou, v rámci jurisdikcie a prevádzkovej hranice, ktorú už kontrolujete. To je menej efektné ako dashboard. Je to tiež menej pravdepodobné, že niekoho zobudí.
Odpoveď na audit je prehratie
Keď sa audítor pýta, prečo bolo rozhodnutie zamietnuté, najhoršia odpoveď je odsek zrekonštruovaný z pamäte. Druhá najhoršia odpoveď je snímka obrazovky. Užitočná odpoveď je: táto verzia knihy pravidiel bežala na tomto vstupe a vyprodukovala tento výstup, tu je kontrolný súčet artefaktu, tu je pravidlo, tu je prehratie. Lattice je postavený tak, aby túto odpoveď umožnil.
Stránka prepája Lattice s automatizovanými rozhodnutiami podľa GDPR, transparentnosťou podľa zákona EÚ o umelej inteligencii, prevádzkovou odolnosťou podľa DORA a zabezpečením dodávateľského reťazca podľa NIS2. Tieto označenia sa môžu stať len propagačným prachom, ak systém nedokáže ukázať nič konkrétne. Tým konkrétnym je artefakt. Zostavenú knihu pravidiel možno pomenovať. Kontrolný súčet dokáže odmietnuť manipuláciu. Zaznamenané vstupy dokážu prehrať rozhodnutie. Bitovo presný výstup znamená, že prepnutie na záložný systém by nemalo potichu zmeniť odpoveď. Spustenie v rámci riadených systémov pomáha vyhnúť sa problému externej služby na rozhodovacej ceste.
Kde má zmysel najskôr
Lattice dáva najväčší zmysel v rozhodovacích bodoch, ktoré sa vyskytujú často a neskôr potrebujú dôkazy. Kontroly zhody pri transakciách. Stanovenie cien a oprávnenosti v čase ponuky. Rozhodnutia o prístupe na bránach. Preverovanie podvodov pred vyrovnaním. Kontroly oprávnenosti vo verejnom sektore. Brány upisovania poistenia. Oprávnenia interných pracovných postupov. Toto sú miesta, kde áno alebo nie nestačí. Systém musí vedieť, ktorá verzia áno alebo nie nastala.
Hodí sa aj na miesta, kde rovnaké rozhodnutie musí zostať rovnaké naprieč servermi. Prepnutie na záložný systém by nemalo zmeniť výsledok zhody. Regionálne nasadenie by nemalo interpretovať pravidlo inak, pretože sa odchýlila verzia knižnice. Auditné prehratie by nemalo vyžadovať, aby rovnaká hostovaná služba dodávateľa stále existovala. Kniha pravidiel by mala byť dostatočne prenosná, aby sa dala spustiť tam, kde ju organizácia kontroluje, a dostatočne explicitná, aby náklady na zmenu zostali nízke.
Preto je otvorený zdroj dôležitý aj tu. Pravidlový engine, ktorý sa podieľa na zhode, prístupe, cenách alebo podvodoch, nie je dekoratívna závislosť. Je súčasťou riadiacej roviny. Ak ho nikto v organizácii nedokáže preskúmať, pripnúť, otestovať a udržiavať, potom kniha pravidiel nie je naozaj ich. Je to prenajatá autorita.
Čo preskúmať pred prijatím
Po prvé, identifikujte rozhodovacie body. Nezačínajte migráciou platformy. Začnite s jednou knihou pravidiel, ktorá dnes spôsobuje problémy. Ako často sa spúšťa? Čo chráni? Kto sa pýta prečo? Čo sa stane, ak je služba nedostupná? Aké dôkazy sú dostupné o šesť mesiacov?
Po druhé, preskúmajte tvar pravidiel. Sú obmedzenia boolovské, aritmetické, lineárne, celočíselné, s konečnou doménou, cestové alebo mäkké? Ktorá trieda backendu by ich mala vlastniť? Ak pravidlo nedokáže vysvetliť, prečo smeruje do rodiny riešiteľov, abstrakcia je príliš magická.
Po tretie, preskúmajte disciplínu artefaktov. Kde je uložené zdrojové pravidlo? Ktoré zostavenie vytvorilo artefakt? Ktorý kontrolný súčet sa načítal? Ktorá verzia aplikácie ho použila? Ktoré vstupy boli zaznamenané? Ktorá cesta prehratia dokazuje odpoveď? Ak je odpoveď rozptýlená cez tri systémy a osobu menom Jan, kniha pravidiel ešte nie je auditným objektom. Je to tradícia.
Ponaučenie
Lattice je príbeh o pravidlovom engine, ale v skutočnosti je to príbeh o riadení. Zostavte knihu pravidiel pred požiadavkou. Zabaľte ju do artefaktu, ktorý aplikácia dokáže mapovať do pamäte. Skontrolujte artefakt pred načítaním. Smerujte obmedzenia do správnej rodiny riešiteľov. Vyhodnocujte v rámci procesu. Prehrajte neskôr s rovnakým vstupom a rovnakou verziou knihy pravidiel.
To nie je očarujúce. Dobre. Obchodné pravidlá by nemali byť očarujúce. Mali by byť nudné, rýchle, explicitné a preskúmateľné. Dôležité rozhodovacie systémy v spoločnosti by nemali závisieť od vzdialených orákul, slučiek parserov a auditnej archeológie. Mali by nosiť svoje knihy pravidiel ako infraštruktúru.
Kniha pravidiel by nemala byť vzdialené orákulum. Mala by byť niečo, čo systém dokáže spustiť, pomenovať a prehrať.