Tinkleliai ir taisyklės, veikiantys procese
Taisyklių knyga neturėtų būti nuotolinis orakulas
Verslo taisyklės paprastai pristatomos kaip kažkas paprasto. Klientas atitinka reikalavimus arba ne. Operacija pavyksta arba nepavyksta. Pasiūlymui taikoma nuolaida. Vartotojas gali pasiekti išteklių. Tada taisyklės išauga, atsiranda išimtys, atitikties reikalavimai prašo įrodymų, ir staiga paprastas patikrinimas tampa politikos paslauga, interpretatoriumi, talpykla, suderinimo darbu ir susitikimu su tiekėju. Nuostabu. Mes iš naujo išradome šviesoforą su prenumeratos planu.
„Lattice“ pradeda nuo mažiau teatrališkos idėjos: taisyklių knyga turėtų veikti ten, kur priimamas sprendimas. Dabartinis „Lattice“ puslapis aprašo „Apache 2.0“ „Rust“ komponentą, kuris iš anksto kompiliuoja taisykles į atmintyje susiejamą dvejetainį artefaktą. Vertinimas yra procese vykdomas suspausto medžio perėjimas. Artefaktas turi kontrolines sumas. Tos pačios taisyklės ir tie patys duomenys aprašomi kaip duodantys tą patį atsakymą palaikomose platformose. Jokiai papildomai paslaugai nereikia būti sprendimo kelyje. Tokia yra naudinga forma.
Tai nėra prieš valdyseną. Tai priešingai. Valdysena silpnėja, kai taisyklės gyvena toli nuo jas naudojančių sistemų, o paaiškinimus tenka rekonstruoti vėliau. Taisyklių knyga, kuri yra versijuojama, kompiliuojama, turi kontrolines sumas, įkeliama į procesą ir gali būti atkurta, auditoriams suteikia kažką konkretesnio nei tai, ko paprašėme politikos paslaugos, o ji atsakė ne. Tas sakinys gali būti teisingas. To nepakanka.
Kompiliuokite vieną kartą, nustokite interpretuoti amžiams
Puslapio eiga aiški: kurti, kompiliuoti, pakuoti, vertinti. Taisyklės ir apribojimai gyvena šalia šaltinio ir versijų istorijos. Kompiliavimas klasifikuoja apribojimus ir priskiria sprendiklio backendą. Pakavimas sukuria dvejetainį artefaktą su XXH3-64 kontrolinėmis sumomis antraštei, turiniui ir failui. Įkėlimas yra sistemos iškvietimas, o ne analizė. Vertinimas procese eina per suspaustą medį. Ši seka svarbi, nes ji paverčia vykdymo laiko darbą kūrimo laiko darbu.
Interpretatoriai patogūs, kol jie nėra kiekvienoje užklausoje. Nuotolinė politikos paslauga patogi, kol tinklo šuolis netampa delsos biudžeto dalimi ir paslauga netampa dar vienu dalyku, kuris gali sutrikti. JIT patogus, kol skirtingi serveriai, versijos ar optimizatoriai netampa paaiškinimo dalimi. „Lattice“ sąmoningai mažiau dramatiškas. Jis sako, kad taisyklių knyga turėtų tapti failu, kurį programa gali susieti ir vykdyti deterministiškai. Užklausos kelias neturėtų kiekvieną kartą iš naujo atrasti taisyklių.
Puslapyje pateikiami dabartinio artefakto kelio etaloniniai skaičiai, įskaitant karštojo vertinimo skaičių, šaltojo paieškos po mmap skaičių ir pralaidumo rodiklius. Tie skaičiai priklauso puslapiui ir jo etaloniniam kontekstui, o ne mitui, kurį reikėtų kopijuoti į kiekvieną būsimą leidimą. Ilgalaikis inžinerinis dalykas yra dizainas: supakuotas artefaktas, talpykloje vietinis vertinimas, jokio analizatoriaus karštajame kelyje, jokio atminties skirstytuvo karštajame kelyje ir jokio tinklo šuolio kiekvienam sprendimui.
Viena taisyklių API neturėtų slėpti sprendiklio realybės
Taisyklės nėra visos vienodos. Kai kurios yra gryni loginiai patikrinimai. Kai kurios sujungia logiką su aritmetika. Kai kurios yra tiesinio programavimo uždaviniai. Kai kurioms reikia sveikųjų skaičių sprendimų. Kai kurios yra baigtinių sričių apribojimai. Kai kurios yra kelio problemos arba minkštieji apribojimai. Rimtas taisyklių variklis neturėtų priversti kiekvieno atvejo eiti pro vieną sprendiklio formos rakto skylutę. Jis turėtų klasifikuoti taisyklę ir nukreipti ją į tinkamą backendą.
The Lattice page names SAT, SMT, LP, MIP, CP, A*, and MaxSAT under one rule API. SAT covers pure boolean rules and feature gates. SMThandles mixed theories like logic, arithmetic, arrays and bitvectors. LP covers continuous optimization. MIP or ILP handles integer decisions. CP handles finite domains and non-linear constraints. A* and MaxSAT cover path and soft-constraint problems. The important product sentence is that the caller writes rules, not solver calls.
That matters for maintainability. If every product team writes solver-specific integration code, the policy layer becomes a collection of clever local tricks. Clever local tricks are expensive in audits because nobody remembers which trick was clever and which one was just Friday.A classified rule surface gives teams one place to inspect the rule, its backend class, the compiled artefact and the answer it produced.
Latency is a business rule too
Decision systems love to pretend latency is a technical afterthought. It is not. If a compliance check sits on every transaction, latency is part of the product. If access control sits at a gateway, latency is part of security. If pricing runs at quote time, latency is part of revenue. If fraud screening runs before settlement, latency ispart of risk. A slow rule can be correct and still operationally wrong.
This is why in-process evaluation matters. The current Lattice page contrasts millisecond-scale interpreted or remote checks with the packed artefact path, and it calls out the cost of network hops, sidecar services and audit gaps. The exact number for one benchmark is less important than the shape of the cost. If one request needs ten checks, maybe the old path survives. If one request needs ten thousand checks, the old path starts taking rent in the request budget. At that point the rule engine is no longer a component. It is the thing users are waiting for.
The operational benefit is not only speed. It is fewer moving parts. No extra policy service. No network path to keep healthy. No separate parser process. No separate cache to explain. The rulebook sits with the application, inside the jurisdiction and operational boundary you already control. That is less glamorous than a dashboard. It is also less likely to wake someone up.
The audit answer is the replay
When an auditor asks why a decision was denied, theworst answer is a paragraph reconstructed from memory. The second-worst answer is a screenshot. The useful answer is: this rulebook version ran on this input and produced this output, here is the artefact checksum, here is the rule, here is the replay. Lattice is built around making that answer possible.
The page ties Lattice to GDPR automated decisions, EU AI Act transparency, DORA operational resilience and NIS2 supply-chain assurance. Those labels can become brochure dust if the system cannot show anything concrete. The concrete part is the artefact. A compiled rulebook can be named. A checksum can reject tampering. Logged inputs can replay the decision. Bit-exact output means failover should not quietly change an answer. Running in process inside controlled systems helps avoid the outside-service problem on the decision path.
Where it fits first
Lattice makes most sense at decision points that happen often and need evidence later. Compliance checks on transactions. Pricing and eligibility at quote time. Access decisions at gateways. Fraud screening before settlement. Public-sector eligibility checks. Insurance underwriting gates. Internal workflow permissions. These are places where yes or no is not enough. The system has to know which version of yes or no happened.
It also fits places where the same decision must stay the same across servers. A failover should not change a compliance result. A regional deployment should not interpret a rule differently because a library version drifted. An audit replay should not need the same hosted vendor service to still exist. The rulebook should be portable enough to run where the organization controls it, and explicit enough that switching costs stay low.
That is why open source matters here too. A rule engine that participates in compliance, access, pricing or fraud is not a decorative dependency. It is part of the control plane. If nobody inside the organization can inspect it, pin it, test it and keep it, then the rulebook is not really theirs. It is rented authority.
What to review before adopting it
First, identify the decision points. Do not start with a platform migration. Start with one rulebook that hurts today. How often does it run? What does it protect? Who asks why? What happens if the service is down? What evidence is available six months later?
Second, review rule shape. Are the constraints boolean, arithmetic, linear, integer, finite-domain, path-like, or soft? Which backend class should own them? If the rule cannot explain why it routes to a solver family, the abstraction is too magical.
Third, review artefact discipline. Where is the source rule stored? Which build produced the artefact? Which checksum loaded? Which application version used it? Which inputs were logged? Which replay path proves the answer? If the answer is spread across three systems and a person named Jan, the rulebook is not yet an audit object. It is a tradition.
The lesson
Lattice is a rules engine story, but it is really a control story. Compile the rulebook before the request. Pack it into an artefact the application can mmap. Check the artefact before loading it. Route constraints to the right solver family. Evaluate in process. Replay later with the same input and the same rulebook version.
That is not glamorous. Good. Business rules should not be glamorous. They should be boring, fast, explicit and reviewable. The important decision systems in a company should not depend on remote oracles, parser loops and audit archaeology. They should carry their rulebooks like infrastructure.
The rulebook should not be a remote oracle. It should be something the system can run, name and replay.