Væv og regelsæt, der kører i processen
Regelbogen skal ikke være et fjernt orakel
Forretningsregler introduceres normalt som noget simpelt. En kunde er berettiget eller ej. En transaktion gennemføres eller fejler. Et tilbud får en rabat. En bruger kan få adgang til en ressource. Så vokser reglerne, undtagelserne kommer til, compliance beder om dokumentation, og pludselig er det simple tjek blevet til en politiktjeneste, en fortolker, en cache, et afstemmingsjob og et møde med en leverandør. Vidunderligt. Vi har genopfundet et trafiklys med et abonnementsabonnement.
Lattice tager udgangspunkt i en mindre teatralsk idé: regelbogen skal køre, hvor beslutningen træffes. Den nuværende Lattice-side beskriver en Apache 2.0 Rust-komponent, der kompilerer regler på forhånd til en hukommelsesmappbar binær artefakt. Evaluering er en in-process gennemgang af en pakket træstruktur. Artefakten bærer kontrolsummer. De samme regler og de samme data beskrives som givende samme svar på understøttede platforme. Der skal ikke ligge nogen ekstra tjeneste i vejen for en beslutning. Det er den nyttige form.
Dette er ikke anti-governance. Det er det modsatte. Governance bliver svagere, når regler ligger langt fra de systemer, der bruger dem, og forklaringer skal rekonstrueres senere. En regelbog, der er versionsstyret, kompileret, checksummet, indlæst i processen og afspilbar, giver revisorer noget mere konkret end "vi spurgte politiktjenesten, og den sagde nej". Den sætning kan være sand. Det er ikke nok.
Kompilér én gang, stop med at fortolke for evigt
Sidepipelinen er klar: forfatter, kompiler, pak, evaluer. Regler og begrænsninger lever ved siden af kildekode og versionshistorik. Kompilering klassificerer begrænsninger og fastlåser solver-backend. Pakning producerer en binær artefakt med XXH3-64-kontrolsummer over header, indhold og fil. Indlæsning er et syscall, ikke en parse. Evaluering gennemgår den pakkede træstruktur i processen. Den rækkefølge betyder noget, fordi den gør runtime-arbejde til build-tid-arbejde.
Fortolkere er praktiske, indtil de ligger på hver eneste anmodning. En fjern politiktjeneste er praktisk, indtil netværksspringet bliver en del af latency-budgettet, og tjenesten bliver endnu en ting, der kan være nede. En JIT er praktisk, indtil forskellige værter, versioner eller optimeringsværktøjer bliver en del af forklaringen. Lattice er bevidst mindre dramatisk. Det siger, at regelbogen skal blive en fil, applikationen kan mappe og eksekvere deterministisk. Anmodningsstien skal ikke opdage reglerne igen hver gang.
Siden rapporterer benchmark-tal for den nuværende artefaktsti, herunder et tal for varm evaluering, et koldt opslag efter mmap og gennemløbstal. Disse tal hører til siden og dens benchmark-kontekst, ikke til en myte, der skal kopieres ind i hver fremtidig udgivelse. Det holdbare ingeniørpunkt er designet: en pakket artefakt, cache-lokal evaluering, ingen parser på den kritiske sti, ingen allokator på den kritiske sti og intet netværksspring pr. beslutning.
En enkelt regel-API skal ikke skjule solver-virkeligheden
Regler er ikke alle ens. Nogle er rene booleske tjek. Nogle kombinerer logik med aritmetik. Nogle er lineære programmer. Nogle kræver heltalsbeslutninger. Nogle er begrænsninger med endeligt domæne. Nogle er sti-problemer eller bløde begrænsninger. En seriøs regelmotor bør ikke tvinge hvert tilfælde gennem ét solver-formet nøglehul. Den bør klassificere reglen og dirigere den til den rigtige backend.
Lattice-siden samler SAT, SMT, LP, MIP, CP, A* og MaxSAT under ét regel-API. SAT dækker rene booleske regler og feature-gates. SMT håndterer blandede teorier som logik, aritmetik, arrays og bitvektorer. LP dækker kontinuerlig optimering. MIP eller ILP håndterer heltalsbeslutninger. CP håndterer endelige domæner og ikke-lineære begrænsninger. A* og MaxSAT dækker sti- og blød-begrænsningsproblemer. Den vigtige produktsætning er, at den, der kalder, skriver regler, ikke solver-kald.
Det betyder noget for vedligeholdelsen. Hvis hvert produktteam skriver solver-specifik integrationskode, bliver policylaget en samling af smarte lokale tricks. Smarte lokale tricks er dyre ved audits, fordi ingen husker, hvilket trick der var smart, og hvilket der bare var fredag. En klassificeret regelflade giver teams ét sted at inspicere reglen, dens backend-klasse, det kompilerede artefakt og det svar, den producerede.
Latens er også en forretningsregel
Beslutningssystemer elsker at lade som om, latens er en teknisk eftertanke. Det er den ikke. Hvis en compliance-kontrol ligger på hver transaktion, er latens en del af produktet. Hvis adgangskontrol ligger ved en gateway, er latens en del af sikkerheden. Hvis prissætning kører ved tilbudstidspunktet, er latens en del af omsætningen. Hvis svindelkontrol kører før afregning, er latens en del af risikoen. En langsom regel kan være korrekt og stadig være operationelt forkert.
Derfor betyder in-process-evaluering noget. Den nuværende Lattice-side kontrasterer fortolkede eller eksterne kontroller i millisekundskala med den pakkede artefakt-sti, og den fremhæver omkostningen ved netværkshop, sidecar-tjenester og audit-gap. Det præcise tal for én benchmark er mindre vigtigt end omkostningens form. Hvis én anmodning kræver ti kontroller, overlever den gamle sti måske. Hvis én anmodning kræver ti tusinde kontroller, begynder den gamle sti at tage husleje i anmodningsbudgettet. På det tidspunkt er regelmotoren ikke længere en komponent. Den er det, brugerne venter på.
Den operationelle fordel er ikke kun hastighed. Det er færre bevægelige dele. Ingen ekstra policy-tjeneste. Ingen netværkssti at holde sund. Ingen separat parser-proces. Ingen separat cache at forklare. Regelbogen ligger sammen med applikationen, inden for den jurisdiktion og operationelle grænse, du allerede kontrollerer. Det er mindre glamourøst end et dashboard. Det er også mindre sandsynligt, at det vækker nogen.
Audit-svaret er replayet
Når en revisor spørger, hvorfor en beslutning blev afvist, er det værste svar et afsnit rekonstrueret fra hukommelsen. Det næstværste svar er et skærmbillede. Det nyttige svar er: denne regelbogsversion kørte på denne input og producerede dette output, her er artefakt-checksummen, her er reglen, her er replayet. Lattice er bygget til at gøre det svar muligt.
Siden kæder Lattice sammen med GDPR-automatiske afgørelser, EU's AI-forordnings gennemsigtighed, DORA's operationelle modstandsdygtighed og NIS2's forsyningskædesikkerhed. De etiketter kan blive til tomme løfter, hvis systemet ikke kan vise noget konkret. Det konkrete er artefakten. En kompileret regelbog kan navngives. En checksum kan afvise manipulation. Loggede input kan afspille afgørelsen. Bit-eksakt output betyder, at failover ikke stille og roligt bør ændre et svar. At køre in process i kontrollerede systemer hjælper med at undgå problemet med eksterne tjenester på beslutningsstien.
Hvor det passer ind først
Lattice giver mest mening ved beslutningspunkter, der sker ofte og har brug for dokumentation senere. Compliance-tjek på transaktioner. Prisfastsættelse og berettigelse ved tilbudstidspunktet. Adgangsafgørelser ved gateways. Svindelscreening før afregning. Berettigelsestjek i den offentlige sektor. Forsikringsgarantiporter. Interne workflow-tilladelser. Det er steder, hvor ja eller nej ikke er nok. Systemet skal vide, hvilken version af ja eller nej der skete.
Det passer også ind på steder, hvor den samme afgørelse skal forblive den samme på tværs af servere. En failover bør ikke ændre et compliance-resultat. En regional implementering bør ikke fortolke en regel forskelligt, fordi en biblioteksversion er blevet forskudt. En audit-afspilning bør ikke kræve, at den samme hosted leverandørtjeneste stadig eksisterer. Regelbogen bør være bærbar nok til at køre, hvor organisationen kontrollerer den, og eksplicit nok til, at skifteomkostningerne forbliver lave.
Derfor betyder open source også noget her. En regel-motor, der deltager i compliance, adgang, prisfastsættelse eller svindel, er ikke en dekorativ afhængighed. Den er en del af kontrolplanet. Hvis ingen inde i organisationen kan inspicere den, fastlåse den, teste den og vedligeholde den, så er regelbogen ikke rigtig deres. Det er lejet autoritet.
Hvad man skal gennemgå, før man adopterer det
For det første: identificér beslutningspunkterne. Start ikke med en platformmigrering. Start med én regelbog, der gør ondt i dag. Hvor ofte kører den? Hvad beskytter den? Hvem spørger hvorfor? Hvad sker der, hvis tjenesten er nede? Hvilken dokumentation er tilgængelig seks måneder senere?
For det andet: gennemgå reglens form. Er begrænsningerne booleske, aritmetiske, lineære, heltalsbaserede, finite-domain, sti-lignende eller bløde? Hvilken backend-klasse bør eje dem? Hvis reglen ikke kan forklare, hvorfor den ruter til en solver-familie, er abstraktionen for magisk.
For det tredje: gennemgå artefakt-disiplinen. Hvor er kilderegelen gemt? Hvilken build producerede artefakten? Hvilken checksum blev indlæst? Hvilken applikationsversion brugte den? Hvilke input blev logget? Hvilken afspilningssti beviser svaret? Hvis svaret er spredt over tre systemer og en person ved navn Jan, er regelbogen endnu ikke et audit-objekt. Det er en tradition.
Lærdommen
Lattice er en historie om en regel-motor, men det er i virkeligheden en historie om kontrol. Kompilér regelbogen før forespørgslen. Pak den ind i en artefakt, applikationen kan mmap'e. Tjek artefakten, før du indlæser den. Rute begrænsninger til den rigtige solver-familie. Evaluer in process. Afspil senere med samme input og samme regelbogsversion.
Det er ikke glamourøst. Godt. Forretningsregler bør ikke være glamourøse. De bør være kedelige, hurtige, eksplicitte og gennemgåelige. De vigtige beslutningssystemer i en virksomhed bør ikke afhænge af eksterne orakler, parser-løkker og audit-arkæologi. De bør bære deres regelbøger som infrastruktur.
Regelbogen bør ikke være et eksternt orakel. Det bør være noget, systemet kan køre, navngive og afspille.