Väv och regelverk som körs i processen
Regelboken ska inte vara ett fjärrorakel
Affärsregler introduceras oftast som något enkelt. En kund är kvalificerad eller inte. En transaktion godkänns eller misslyckas. En offert får rabatt. En användare kan komma åt en resurs. Sedan växer reglerna, undantagen dyker upp, compliance kräver bevis, och plötsligt har den enkla kontrollen blivit en policymotor, en tolk, en cache, ett avstämningsjobb och ett möte med en leverantör. Underbart. Vi har återuppfunnit en trafiksignal med en prenumerationsplan.
Lattice utgår från en mindre teatralisk idé: regelboken ska köras där beslutet fattas. Den aktuella Lattice-sidan beskriver en Apache 2.0 Rust-komponent som kompilerar regler i förväg till en minnesmappningsbar binär artefakt. Utvärdering är en in-process genomgång av ett packat träd. Artefakten bär kontrollsummor. Samma regler och samma data beskrivs ge samma svar på alla stödda plattformar. Ingen extra tjänst behöver ligga i vägen för ett beslut. Det är den användbara formen.
Detta är inte anti-governance. Det är tvärtom. Governance försvagas när regler ligger långt från de system som använder dem och förklaringar måste rekonstrueras i efterhand. En regelbok som är versionshanterad, kompilerad, kontrollsummerad, inladdad i processen och uppspelbar ger revisorer något mer konkret än vi frågade policymotorn och den sa nej. Den meningen kan vara sann. Det räcker inte.
Kompilera en gång, sluta tolka för alltid
Pipelinen på sidan är tydlig: skapa, kompilera, packa, utvärdera. Regler och villkor ligger bredvid källkod och versionshistorik. Kompileringen klassificerar villkoren och låser fast lösningsmotorn. Packningen producerar en binär artefakt med XXH3-64-kontrollsummor över huvud, innehåll och fil. Inläsning är ett syscall, inte en parsning. Utvärderingen går igenom det packade trädet i processen. Den sekvensen spelar roll eftersom den gör om körtidsarbete till byggtidsarbete.
Tolkar är praktiska tills de ligger på varje förfrågan. En fjärrstyrd policymotor är praktisk tills nätverkshoppet blir en del av latensbudgeten och tjänsten blir ytterligare en sak som kan ligga nere. En JIT är praktisk tills olika värdar, versioner eller optimerare blir en del av förklaringen. Lattice är medvetet mindre dramatisk. Det säger att regelboken ska bli en fil som applikationen kan mappa och exekvera deterministiskt. Förfrågningssökvägen ska inte behöva upptäcka reglerna på nytt varje gång.
Sidan rapporterar prestandasiffror för den aktuella artefaktsökvägen, inklusive en varm utvärderingssiffra, en kall uppslagning efter mmap och genomströmningssiffror. De siffrorna tillhör sidan och dess prestandakontext, inte en myt som ska kopieras in i varje framtida release. Den bestående tekniska poängen är designen: en packad artefakt, cache-lokal utvärdering, ingen parser på den kritiska sökvägen, ingen allokerare på den kritiska sökvägen och inget nätverkshopp per beslut.
Ett enda regel-API ska inte dölja lösarens verklighet
Regler är inte alla likadana. Vissa är rena booleska kontroller. Vissa kombinerar logik med aritmetik. Vissa är linjära program. Vissa kräver heltalsbeslut. Vissa är ändliga domänvillkor. Vissa är sökvägsproblem eller mjuka villkor. En seriös regelmotor ska inte tvinga varje fall genom ett enda lösarformat nyckelhål. Den ska klassificera regeln och dirigera den till rätt motor.
The Lattice-sidan samlar SAT, SMT, LP, MIP, CP, A* och MaxSAT under ett gemensamt regel-API. SAT hanterar rena booleska regler och funktionsflaggor. SMT hanterar blandade teorier som logik, aritmetik, arrayer och bitvektorer. LP täcker kontinuerlig optimering. MIP eller ILP hanterar heltalsbeslut. CP hanterar ändliga domäner och icke-linjära begränsningar. A* och MaxSAT täcker problem med sökvägar respektive mjuka begränsningar. Den viktiga produktsatsen är att anroparen skriver regler, inte solveranrop.
Det spelar roll för underhållbarheten. Om varje produktteam skriver solver-specifik integrationskod blir policylagret en samling smarta lokala knep. Smarta lokala knep är dyra vid granskningar, för ingen minns vilket knep som var smart och vilket som bara var fredag. En klassificerad regelyta ger teamen en enda plats att inspektera regeln, dess backendklass, det kompilerade artefakten och det svar den producerade.
Latens är också en affärsregel
Beslutssystem älskar att låtsas att latens är en teknisk eftertanke. Det är det inte. Om en regelefterlevnadskontroll ligger på varje transaktion är latens en del av produkten. Om åtkomstkontroll ligger i en gateway är latens en del av säkerheten. Om prissättning sker vid offerttillfället är latens en del av intäkterna. Om bedrägerikontroll sker före avveckling är latens en del av risken. En långsam regel kan vara korrekt och ändå operativt fel.
Det är därför utvärdering i processen spelar roll. Den nuvarande Lattice-sidan ställer millisekundsskalade tolkade eller fjärrstyrda kontroller mot den packade artefaktvägen, och den pekar på kostnaden för nätverkshopp, sidecar-tjänster och granskningsluckor. Det exakta siffran för ett riktmärke är mindre viktigt än kostnadens form. Om en begäran behöver tio kontroller kanske den gamla vägen överlever. Om en begäran behöver tiotusen kontroller börjar den gamla vägen ta hyra i begärandebudgeten. Vid den punkten är regelmotorn inte längre en komponent. Det är det som användarna väntar på.
Den operativa fördelen är inte bara hastighet. Det är färre rörliga delar. Ingen extra policytjänst. Ingen nätverksväg att hålla frisk. Ingen separat parsningsprocess. Ingen separat cache att förklara. Regelboken ligger med applikationen, inom den jurisdiktion och operativa gräns du redan kontrollerar. Det är mindre glamoröst än en instrumentpanel. Det är också mindre sannolikt att väcka någon mitt i natten.
Granskningssvaret är reprisen
När en revisor frågar varför ett beslut nekades är det sämsta svaret ett stycke rekonstruerat ur minnet. Det näst sämsta svaret är en skärmdump. Det användbara svaret är: den här regelboksversionen kördes på den här indatan och producerade den här utdatan, här är artefaktens kontrollsumma, här är regeln, här är reprisen. Lattice är byggt för att göra det svaret möjligt.
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.