Lattice a pravidla běžící v procesu
Pravidla by neměla být vzdáleným orákulem
Business pravidla se obvykle představují jako něco jednoduchého. Zákazník je způsobilý, nebo není. Transakce projde, nebo selže. Nabídka dostane slevu. Uživatel může získat přístup ke zdroji. Pak pravidla rostou, přicházejí výjimky, compliance žádá o důkazy, a najednou se z jednoduché kontroly stane policy služba, interpret, cache, úloha na odsouhlasení a schůzka s dodavatelem. Skvělé. Znovu jsme vynalezli semafor s předplatným.
Lattice začíná méně divadelní myšlenkou: pravidla by měla běžet tam, kde se rozhodnutí dělá. Aktuální stránka Lattice popisuje komponentu v Rustu pod licencí Apache 2.0, která kompiluje pravidla předem do binárního artefaktu mapovatelného do paměti. Vyhodnocení je procházení zabaleného stromu v rámci procesu. Artefakt nese kontrolní součty. Stejná pravidla a stejná data mají na podporovaných cílech produkovat stejnou odpověď. Na cestě rozhodnutí nemusí sedět žádná další služba. To je ten užitečný tvar.
Tohle není proti governance. Je to pravý opak. Governance slábne, když pravidla žijí daleko od systémů, které je používají, a vysvětlení se musí později rekonstruovat. Pravidla, která jsou verzovaná, zkompilovaná, opatřená kontrolními součty, načtená v procesu a přehrávatelná, dávají auditorům něco konkrétnějšího než „zeptali jsme se policy služby a ta řekla ne“. Ta věta může být pravdivá. Nestačí to.
Zkompilujte jednou a přestaňte navždy interpretovat
Pipeline na stránce je jasná: vytvořit, zkompilovat, zabalit, vyhodnotit. Pravidla a omezení žijí vedle zdrojového kódu a historie verzí. Kompilace klasifikuje omezení a ukotví solver backend. Balení vytvoří binární artefakt s XXH3-64 kontrolními součty nad hlavičkou, obsahem a souborem. Načtení je syscall, ne parsování. Vyhodnocení prochází zabalený strom v procesu. Tato sekvence je důležitá, protože převádí práci za běhu na práci při buildu.
Interpretry jsou pohodlné, dokud nesedí na každém požadavku. Vzdálená policy služba je pohodlná, dokud se síťový hop nestane součástí rozpočtu latence a služba se nestane další věcí, která může spadnout. JIT je pohodlný, dokud se různé hosty, verze nebo optimalizátory nestanou součástí vysvětlení. Lattice je záměrně méně dramatický. Říká, že pravidla by se měla stát souborem, který aplikace může mapovat a deterministicky vyhodnocovat. Cesta požadavku by neměla pravidla pokaždé znovu objevovat.
Stránka uvádí benchmarková čísla pro aktuální cestu artefaktu, včetně čísla pro horké vyhodnocení, studeného vyhledání po mmap a propustnosti. Tato čísla patří stránce a jejímu benchmarkovému kontextu, ne mýtu, který by se měl kopírovat do každého budoucího vydání. Trvalý technický bod je návrh: zabalený artefakt, vyhodnocení lokální vůči cache, žádný parser na kritické cestě, žádný alokátor na kritické cestě a žádný síťový hop na rozhodnutí.
Jedno API pro pravidla by nemělo skrývat realitu solverů
Pravidla nejsou všechna stejná. Některá jsou čistě booleovské kontroly. Některá kombinují logiku s aritmetikou. Některá jsou lineární programy. Některá potřebují celočíselná rozhodnutí. Některá jsou omezení konečné domény. Některá jsou problémy cest nebo měkká omezení. Seriózní engine pro pravidla by neměl tlačit každý případ jedinou klíčovou dírkou ve tvaru solveru. Měl by pravidlo klasifikovat a směrovat ho na správný backend.
Stránka Lattice sdružuje SAT, SMT, LP, MIP, CP, A* a MaxSAT pod jedno jednotné API pro pravidla. SAT pokrývá čistě booleovská pravidla a funkční brány. SMT zpracovává smíšené teorie, jako je logika, aritmetika, pole a bitové vektory. LP pokrývá spojitou optimalizaci. MIP neboli ILP řeší celočíselná rozhodnutí. CP řeší konečné domény a nelineární omezení. A* a MaxSAT pokrývají problémy s cestami a měkkými omezeními. Klíčová věta pro produkt je, že volající píše pravidla, ne volání solverů.
To je důležité pro udržovatelnost. Pokud každý produktový tým píše vlastní integrační kód pro konkrétní solver, stane se z politické vrstvy sbírka chytrých lokálních triků. Chytré lokální triky jsou při auditech drahé, protože nikdo si nepamatuje, který trik byl chytrý a který byl jen páteční rychlovka. Klasifikovaný povrch pravidel dává týmům jedno místo, kde si prohlédnou pravidlo, jeho třídu backendu, zkompilovaný artefakt a odpověď, kterou vyprodukoval.
Latence je také obchodní pravidlo
Rozhodovací systémy rády předstírají, že latence je technický dodatek. Není. Pokud kontrola shody běží na každé transakci, je latence součástí produktu. Pokud řízení přístupu stojí na bráně, je latence součástí bezpečnosti. Pokud se ceny počítají v době nabídky, je latence součástí příjmů. Pokud se screening podvodů spouští před vypořádáním, je latence součástí rizika. Pomalé pravidlo může být správné a přesto provozně špatné.
Proto záleží na vyhodnocení v rámci procesu. Současná stránka Lattice srovnává interpretované nebo vzdálené kontroly v řádu milisekund s cestou zabaleného artefaktu a upozorňuje na náklady síťových skoků, vedlejších služeb a mezer v auditu. Přesné číslo jednoho benchmarku je méně důležité než tvar nákladů. Pokud jeden požadavek potřebuje deset kontrol, stará cesta možná přežije. Pokud jeden požadavek potřebuje deset tisíc kontrol, začne stará cesta zabírat místo v rozpočtu požadavku. V tu chvíli už pravidlový engine není komponenta. Je to to, na co uživatelé čekají.
Provozní přínos není jen rychlost. Je to méně pohyblivých částí. Žádná další služba pro pravidla. Žádná síťová cesta, kterou je třeba udržovat zdravou. Žádný samostatný proces parseru. Žádná samostatná mezipaměť, kterou je třeba vysvětlovat. Kniha pravidel žije s aplikací, uvnitř jurisdikce a provozní hranice, kterou už ovládáte. To je méně okázalé než dashboard. Je to také méně pravděpodobné, že někoho probudí uprostřed noci.
Odpověď pro audit je přehrání
Když se auditor zeptá, proč bylo rozhodnutí zamítnuto, nejhorší odpověď je odstavec rekonstruovaný z paměti. Druhá nejhorší odpověď je snímek obrazovky. Užitečná odpověď je: tato verze knihy pravidel běžela na tomto vstupu a vytvořila tento výstup, tady je kontrolní součet artefaktu, tady je pravidlo, tady je přehrání. Lattice je postaven na tom, aby takovou odpověď umožnil.
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.