Siatka i reguły działające w procesie
Regulamin nie powinien być zdalną wyrocznią
Reguły biznesowe są zwykle przedstawiane jako coś prostego. Klient kwalifikuje się albo nie. Transakcja przechodzi albo nie. Oferta dostaje rabat. Użytkownik może uzyskać dostęp do zasobu. Potem reguły rosną, pojawiają się wyjątki, compliance żąda dowodów i nagle prosta kontrola staje się serwisem polityk, interpreterem, pamięcią podręczną, zadaniem uzgadniania i spotkaniem z dostawcą. Wspaniale. Wymyśliliśmy na nowo światło drogowe z planem subskrypcji.
Lattice zaczyna od mniej teatralnego pomysłu: regulamin powinien działać tam, gdzie podejmowana jest decyzja. Obecna strona Lattice opisuje komponent Rusta na licencji Apache 2.0, który kompiluje reguły z wyprzedzeniem do artefaktu binarnego z możliwością mapowania w pamięci. Ewaluacja to przejście po spakowanym drzewie w procesie. Artefakt zawiera sumy kontrolne. Te same reguły i te same dane opisano jako dające ten sam wynik na obsługiwanych platformach. Żadna dodatkowa usługa nie musi znajdować się na ścieżce decyzji. To jest użyteczny kształt.
To nie jest anty-zarządzanie. To coś przeciwnego. Zarządzanie słabnie, gdy reguły żyją daleko od systemów, które ich używają, a wyjaśnienia trzeba później rekonstruować. Regulamin, który jest wersjonowany, kompilowany, opatrzony sumą kontrolną, ładowany w procesie i odtwarzalny, daje audytorom coś bardziej konkretnego niż „zapytaliśmy serwis polityk, a on powiedział nie”. To zdanie może być prawdziwe. To nie wystarczy.
Skompiluj raz, przestań interpretować na zawsze
Potok strony jest jasny: autor, kompilacja, pakowanie, ewaluacja. Reguły i ograniczenia znajdują się obok kodu źródłowego i historii wersji. Kompilacja klasyfikuje ograniczenia i przypina backend solvera. Pakowanie tworzy artefakt binarny z sumami kontrolnymi XXH3-64 dla nagłówka, treści i pliku. Ładowanie to wywołanie systemowe, a nie parsowanie. Ewaluacja przechodzi po spakowanym drzewie w procesie. Ta sekwencja ma znaczenie, ponieważ zamienia pracę w czasie wykonywania na pracę w czasie budowania.
Interpretery są wygodne, dopóki nie znajdą się na każdym żądaniu. Zdalny serwis polityk jest wygodny, dopóki skok sieciowy nie stanie się częścią budżetu opóźnień, a serwis nie stanie się kolejną rzeczą, która może być niedostępna. JIT jest wygodny, dopóki różne hosty, wersje lub optymalizatory nie staną się częścią wyjaśnienia. Lattice celowo jest mniej dramatyczny. Mówi, że regulamin powinien stać się plikiem, który aplikacja może zmapować i wykonywać deterministycznie. Ścieżka żądania nie powinna za każdym razem odkrywać reguł na nowo.
Strona podaje liczby z benchmarków dla bieżącej ścieżki artefaktu, w tym liczbę dla gorącej ewaluacji, zimny odczyt po mmap i wartości przepustowości. Te liczby należą do strony i jej kontekstu benchmarku, a nie do mitu, który należy kopiować do każdej przyszłej wersji. Trwały punkt inżynieryjny to projekt: spakowany artefakt, ewaluacja lokalna dla pamięci podręcznej, brak parsera na ścieżce krytycznej, brak alokatora na ścieżce krytycznej i brak skoku sieciowego na decyzję.
Pojedyncze API reguł nie powinno ukrywać rzeczywistości solvera
Reguły nie są wszystkie takie same. Niektóre to czyste kontrole logiczne. Niektóre łączą logikę z arytmetyką. Niektóre to programy liniowe. Niektóre wymagają decyzji całkowitoliczbowych. Niektóre to ograniczenia skończonych dziedzin. Niektóre to problemy ścieżek lub ograniczenia miękkie. Poważny silnik reguł nie powinien przepychać każdego przypadku przez jedną dziurkę od klucza w kształcie solvera. Powinien klasyfikować regułę i kierować ją do właściwego backendu.
Strona Lattice obejmuje SAT, SMT, LP, MIP, CP, A* i MaxSAT w ramach jednego API reguł. SAT obsługuje reguły czysto boolowskie i bramki funkcji. SMT obsługuje teorie mieszane, takie jak logika, arytmetyka, tablice i wektory bitowe. LP obejmuje optymalizację ciągłą. MIP lub ILP obsługuje decyzje całkowitoliczbowe. CP obsługuje dziedziny skończone i ograniczenia nieliniowe. A* i MaxSAT obejmują problemy ścieżek i ograniczeń miękkich. Najważniejsze zdanie produktowe brzmi: autor pisze reguły, a nie wywołania solverów.
To ma znaczenie dla łatwości utrzymania. Jeśli każdy zespół produktowy pisze własny kod integracyjny dla solverów, warstwa polityk staje się zbiorem sprytnych lokalnych sztuczek. Sprytne lokalne sztuczki są kosztowne w audytach, bo nikt nie pamięta, która sztuczka była sprytna, a która była tylko piątkowym pomysłem. Sklasyfikowana powierzchnia reguł daje zespołom jedno miejsce do sprawdzenia reguły, jej klasy zaplecza, skompilowanego artefaktu i wygenerowanej odpowiedzi.
Opóźnienie też jest regułą biznesową
Systemy decyzyjne lubią udawać, że opóźnienie to techniczny dodatek. Tak nie jest. Jeśli kontrola zgodności leży na każdej transakcji, opóźnienie jest częścią produktu. Jeśli kontrola dostępu działa na bramie, opóźnienie jest częścią bezpieczeństwa. Jeśli wycena działa w momencie ofertowania, opóźnienie jest częścią przychodu. Jeśli screening oszustw działa przed rozliczeniem, opóźnienie jest częścią ryzyka. Wolna reguła może być poprawna, a mimo to operacyjnie błędna.
Dlatego ewaluacja w procesie ma znaczenie. Obecna strona Lattice porównuje interpretowane lub zdalne kontrole w skali milisekund ze ścieżką spakowanych artefaktów i wskazuje koszt skoków sieciowych, usług bocznych i luk audytowych. Dokładna liczba dla jednego benchmarku jest mniej ważna niż kształt kosztu. Jeśli jedno żądanie wymaga dziesięciu kontroli, stara ścieżka może wystarczyć. Jeśli jedno żądanie wymaga dziesięciu tysięcy kontroli, stara ścieżka zaczyna zajmować miejsce w budżecie żądania. W tym momencie silnik reguł przestaje być komponentem. Staje się tym, na co czekają użytkownicy.
Korzyść operacyjna to nie tylko szybkość. To mniej ruchomych części. Żadnej dodatkowej usługi polityk. Żadnej ścieżki sieciowej do utrzymania. Żadnego osobnego procesu parsera. Żadnej osobnej pamięci podręcznej do wyjaśniania. Księga reguł siedzi razem z aplikacją, w obrębie jurysdykcji i granic operacyjnych, które już kontrolujesz. To mniej efektowne niż dashboard. Ale też mniej prawdopodobne, że kogoś obudzi w nocy.
Odpowiedzią na audyt jest powtórka
Gdy audytor pyta, dlaczego decyzja została odrzucona, najgorszą odpowiedzią jest akapit zrekonstruowany z pamięci. Drugą najgorszą odpowiedzią jest zrzut ekranu. Użyteczna odpowiedź brzmi: ta wersja księgi reguł działała na tych danych wejściowych i wygenerowała ten wynik, oto suma kontrolna artefaktu, oto reguła, oto powtórka. Lattice jest zbudowany wokół umożliwienia takiej odpowiedzi.
Ta strona wiąże Lattice z automatycznymi decyzjami RODO, przejrzystością aktu o sztucznej inteligencji UE, odpornością operacyjną DORA i zapewnieniem łańcucha dostaw NIS2. Te etykiety mogą zamienić się w pustą deklarację, jeśli system nie pokaże niczego konkretnego. Konkretną częścią jest artefakt. Skompilowany zbiór reguł można nazwać. Suma kontrolna może odrzucić ingerencję. Zarejestrowane dane wejściowe mogą odtworzyć decyzję. Wynik zgodny co do bitu oznacza, że przełączenie awaryjne nie powinno po cichu zmienić odpowiedzi. Działanie w procesie w kontrolowanych systemach pomaga uniknąć problemu zewnętrznej usługi na ścieżce decyzyjnej.
Gdzie sprawdza się w pierwszej kolejności
Lattice ma największy sens w punktach decyzyjnych, które występują często i wymagają dowodów później. Kontrole zgodności transakcji. Wycena i kwalifikowalność w momencie oferty. Decyzje o dostępie na bramkach. Przesiewanie oszustw przed rozliczeniem. Kontrole kwalifikowalności w sektorze publicznym. Bramki underwritingu ubezpieczeniowego. Wewnętrzne uprawnienia w przepływach pracy. To miejsca, gdzie samo tak lub nie nie wystarcza. System musi wiedzieć, która wersja tak lub nie miała miejsce.
Sprawdza się również tam, gdzie ta sama decyzja musi pozostać taka sama na różnych serwerach. Przełączenie awaryjne nie powinno zmienić wyniku zgodności. Wdrożenie regionalne nie powinno interpretować reguły inaczej, ponieważ wersja biblioteki się rozjechała. Odtworzenie audytu nie powinno wymagać, aby ta sama hostowana usługa dostawcy nadal istniała. Zbiór reguł powinien być na tyle przenośny, aby działał tam, gdzie organizacja go kontroluje, i na tyle jednoznaczny, aby koszty zmiany pozostały niskie.
Dlatego otwarte oprogramowanie też ma tu znaczenie. Silnik reguł, który uczestniczy w zgodności, dostępie, wycenie lub wykrywaniu oszustw, nie jest dekoracyjną zależnością. Jest częścią płaszczyzny kontroli. Jeśli nikt w organizacji nie może go przejrzeć, przypiąć, przetestować i utrzymać, to zbiór reguł nie jest naprawdę ich. To wynajęty autorytet.
Co sprawdzić przed wdrożeniem
Po pierwsze, zidentyfikuj punkty decyzyjne. Nie zaczynaj od migracji platformy. Zacznij od jednego zbioru reguł, który boli dziś. Jak często działa? Co chroni? Kto pyta dlaczego? Co się dzieje, gdy usługa jest niedostępna? Jakie dowody są dostępne sześć miesięcy później?
Po drugie, przejrzyj kształt reguł. Czy ograniczenia są boolowskie, arytmetyczne, liniowe, całkowitoliczbowe, o skończonej dziedzinie, ścieżkowe czy miękkie? Która klasa backendu powinna je obsługiwać? Jeśli reguła nie potrafi wyjaśnić, dlaczego trafia do rodziny solverów, abstrakcja jest zbyt magiczna.
Po trzecie, przejrzyj dyscyplinę artefaktów. Gdzie przechowywany jest źródłowy zbiór reguł? Która kompilacja wyprodukowała artefakt? Która suma kontrolna została załadowana? Która wersja aplikacji go użyła? Które dane wejściowe zostały zarejestrowane? Która ścieżka odtworzenia dowodzi wyniku? Jeśli odpowiedź jest rozproszona po trzech systemach i osobie o imieniu Jan, zbiór reguł nie jest jeszcze obiektem audytu. To tradycja.
Lekcja
Lattice to historia silnika reguł, ale tak naprawdę to historia kontroli. Skompiluj zbiór reguł przed żądaniem. Zapakuj go do artefaktu, który aplikacja może zmapować w pamięci. Sprawdź artefakt przed załadowaniem. Kieruj ograniczenia do właściwej rodziny solverów. Obliczaj w procesie. Odtwarzaj później z tymi samymi danymi wejściowymi i tą samą wersją zbioru reguł.
To nie jest efektowne. Dobrze. Reguły biznesowe nie powinny być efektowne. Powinny być nudne, szybkie, jednoznaczne i możliwe do przejrzenia. Ważne systemy decyzyjne w firmie nie powinny zależeć od zdalnych wyroczni, pętli parserów i archeologii audytowej. Powinny nosić swoje zbiory reguł jak infrastrukturę.
Zbiór reguł nie powinien być zdalną wyrocznią. Powinien być czymś, co system może uruchomić, nazwać i odtworzyć.