Lattice und Regelwerke, die im Prozess laufen
Das Regelwerk sollte kein entferntes Orakel sein
Geschäftsregeln werden meist als etwas Einfaches eingeführt. Ein Kunde ist berechtigt oder nicht. Eine Transaktion besteht oder scheitert. Ein Angebot erhält einen Rabatt. Ein Benutzer darf auf eine Ressource zugreifen. Dann wachsen die Regeln, die Ausnahmen kommen, die Compliance verlangt Nachweise, und plötzlich ist aus der einfachen Prüfung ein Policydienst geworden, ein Interpreter, ein Cache, ein Abgleichsjob und ein Anbietertreffen. Wunderbar. Wir haben eine Ampel mit einem Abonnementmodell neu erfunden.
Lattice geht von einer weniger theatralischen Idee aus: Das Regelwerk sollte dort laufen, wo die Entscheidung getroffen wird. Die aktuelle Lattice-Seite beschreibt eine Apache-2.0-Rust-Komponente, die Regeln im Voraus zu einem speicherzuordnungsfähigen Binärartefakt kompiliert. Die Auswertung ist ein In-Process-Durchlauf durch einen gepackten Baum. Das Artefakt trägt Prüfsummen. Dieselben Regeln und dieselben Daten werden so beschrieben, dass sie auf unterstützten Zielen dieselbe Antwort erzeugen. Kein zusätzlicher Dienst muss im Pfad einer Entscheidung liegen. Das ist die nützliche Form.
Das ist nicht gegen Governance. Es ist das Gegenteil. Governance wird schwächer, wenn Regeln weit entfernt von den Systemen leben, die sie nutzen, und Erklärungen später rekonstruiert werden müssen. Ein Regelwerk, das versioniert, kompiliert, mit Prüfsummen versehen, im Prozess geladen und wiederholbar ist, gibt Prüfern etwas Konkreteres als „wir haben den Policydienst gefragt und er hat Nein gesagt“. Dieser Satz könnte wahr sein. Er reicht nicht aus.
Einmal kompilieren, nie wieder interpretieren
Die Seitenpipeline ist klar: erstellen, kompilieren, packen, auswerten. Regeln und Constraints liegen neben Quellcode und Versionshistorie. Die Kompilierung klassifiziert Constraints und legt das Solver-Backend fest. Das Packen erzeugt ein Binärartefakt mit XXH3-64-Prüfsummen über Header, Inhalt und Datei. Das Laden ist ein Syscall, kein Parsen. Die Auswertung durchläuft den gepackten Baum im Prozess. Diese Reihenfolge ist wichtig, weil sie Laufzeitarbeit in Build-Zeit-Arbeit verwandelt.
Interpreter sind praktisch, bis sie auf jeder Anfrage sitzen. Ein entfernter Policydienst ist praktisch, bis der Netzwerk-Hop Teil des Latenzbudgets wird und der Dienst zu einer weiteren Sache wird, die ausfallen kann. Ein JIT ist praktisch, bis verschiedene Hosts, Versionen oder Optimierer Teil der Erklärung werden. Lattice ist bewusst weniger dramatisch. Es sagt, das Regelwerk sollte eine Datei werden, die die Anwendung deterministisch abbilden und ausführen kann. Der Anforderungspfad sollte die Regeln nicht jedes Mal neu entdecken.
Die Seite berichtet Benchmark-Zahlen für den aktuellen Artefaktpfad, darunter eine Zahl für heiße Auswertung, einen Kaltstart-Lookup nach mmap und Durchsatzzahlen. Diese Zahlen gehören zur Seite und ihrem Benchmark-Kontext, nicht zu einem Mythos, der in jede zukünftige Veröffentlichung kopiert werden sollte. Der dauerhafte technische Punkt ist das Design: ein gepacktes Artefakt, cache-lokale Auswertung, kein Parser im heißen Pfad, kein Allokator im heißen Pfad und kein Netzwerk-Hop pro Entscheidung.
Eine einzige Regel-API sollte die Solver-Realität nicht verbergen
Regeln sind nicht alle gleich. Einige sind reine Boolesche Prüfungen. Einige kombinieren Logik mit Arithmetik. Einige sind lineare Programme. Einige benötigen ganzzahlige Entscheidungen. Einige sind Constraints mit endlichen Domänen. Einige sind Pfadprobleme oder weiche Constraints. Eine ernsthafte Regel-Engine sollte nicht jeden Fall durch ein einziges solverförmiges Schlüsselloch zwingen. Sie sollte die Regel klassifizieren und an das richtige Backend weiterleiten.
Die Lattice-Seite fasst SAT, SMT, LP, MIP, CP, A* und MaxSAT unter einer einheitlichen Regel-API zusammen. SAT deckt reine boolesche Regeln und Feature-Gates ab. SMT behandelt gemischte Theorien wie Logik, Arithmetik, Arrays und Bitvektoren. LP deckt kontinuierliche Optimierung ab. MIP bzw. ILP behandelt ganzzahlige Entscheidungen. CP behandelt endliche Domänen und nichtlineare Nebenbedingungen. A* und MaxSAT decken Pfad- und Soft-Constraint-Probleme ab. Der zentrale Produktsatz lautet: Der Aufrufer schreibt Regeln, keine Solver-Aufrufe.
Das ist für die Wartbarkeit entscheidend. Wenn jedes Produktteam solver-spezifischen Integrationscode schreibt, wird die Policy-Ebene zu einer Sammlung cleverer lokaler Tricks. Clevere lokale Tricks sind in Audits teuer, weil sich niemand merkt, welcher Trick clever war und welcher nur Freitag war. Eine klassifizierte Regeloberfläche gibt Teams einen Ort, um die Regel, ihre Backend-Klasse, das kompilierte Artefakt und die erzeugte Antwort zu prüfen.
Latenz ist auch eine Geschäftsregel
Entscheidungssysteme tun gern so, als sei Latenz ein technisches Randthema. Das ist sie nicht. Wenn eine Compliance-Prüfung auf jeder Transaktion sitzt, ist Latenz Teil des Produkts. Wenn Zugriffskontrolle an einem Gateway sitzt, ist Latenz Teil der Sicherheit. Wenn Preisberechnung zur Angebotszeit läuft, ist Latenz Teil des Umsatzes. Wenn Betrugsprüfung vor der Abwicklung läuft, ist Latenz Teil des Risikos. Eine langsame Regel kann korrekt und trotzdem operativ falsch sein.
Deshalb ist die Auswertung im Prozess wichtig. Die aktuelle Lattice-Seite stellt interpretierte oder entfernte Prüfungen im Millisekundenbereich dem Pfad mit gepackten Artefakten gegenüber und benennt die Kosten von Netzwerk-Hops, Sidecar-Diensten und Audit-Lücken. Die genaue Zahl eines Benchmarks ist weniger wichtig als die Form der Kosten. Wenn eine Anfrage zehn Prüfungen benötigt, überlebt der alte Pfad vielleicht. Wenn eine Anfrage zehntausend Prüfungen benötigt, beginnt der alte Pfad Miete im Anfragebudget zu nehmen. An diesem Punkt ist die Regel-Engine keine Komponente mehr. Sie ist das, worauf die Nutzer warten.
Der operative Nutzen liegt nicht nur in der Geschwindigkeit. Es sind weniger bewegliche Teile. Kein zusätzlicher Policy-Dienst. Kein Netzwerkpfad, der gesund gehalten werden muss. Kein separater Parser-Prozess. Kein separater Cache, der erklärt werden muss. Das Regelwerk sitzt bei der Anwendung, innerhalb der Zuständigkeits- und Betriebsgrenze, die Sie bereits kontrollieren. Das ist weniger glamourös als ein Dashboard. Es ist auch weniger wahrscheinlich, dass es jemanden nachts aufweckt.
Die Audit-Antwort ist das Replay
Wenn ein Prüfer fragt, warum eine Entscheidung abgelehnt wurde, ist die schlechteste Antwort ein aus dem Gedächtnis rekonstruierter Absatz. Die zweitschlechteste Antwort ist ein Screenshot. Die nützliche Antwort lautet: Diese Regelwerksversion lief mit dieser Eingabe und erzeugte diese Ausgabe, hier ist die Artefakt-Prüfsumme, hier ist die Regel, hier ist das Replay. Lattice ist darauf ausgelegt, diese Antwort möglich zu machen.
Die Seite verknüpft Lattice mit automatisierten Entscheidungen im Sinne der DSGVO, Transparenz nach dem EU AI Act, operativer Resilienz nach DORA und Lieferketten-Absicherung nach NIS2. Diese Etiketten können zu bloßer Werbeprosa werden, wenn das System nichts Konkretes vorweisen kann. Das Konkrete ist das Artefakt. Ein kompiliertes Regelwerk kann benannt werden. Eine Prüfsumme kann Manipulation zurückweisen. Protokollierte Eingaben können die Entscheidung erneut abspielen. Bitgenaue Ausgabe bedeutet, dass ein Failover eine Antwort nicht stillschweigend verändern sollte. Die Ausführung im Prozess innerhalb kontrollierter Systeme hilft, das Problem externer Dienste auf dem Entscheidungspfad zu vermeiden.
Wo es zuerst passt
Lattice ist am sinnvollsten an Entscheidungspunkten, die häufig vorkommen und später Belege benötigen. Compliance-Prüfungen bei Transaktionen. Preisgestaltung und Eignung zum Zeitpunkt des Angebots. Zugriffsentscheidungen an Gateways. Betrugsprüfung vor dem Abschluss. Eignungsprüfungen im öffentlichen Sektor. Versicherungsunterzeichnungs-Gates. Interne Workflow-Berechtigungen. Dies sind Orte, an denen Ja oder Nein nicht ausreicht. Das System muss wissen, welche Version von Ja oder Nein stattgefunden hat.
Es passt auch an Orte, an denen dieselbe Entscheidung über Server hinweg gleich bleiben muss. Ein Failover sollte ein Compliance-Ergebnis nicht verändern. Eine regionale Bereitstellung sollte eine Regel nicht anders interpretieren, nur weil eine Bibliotheksversion abgewichen ist. Eine Audit-Wiedergabe sollte nicht davon abhängen, dass derselbe gehostete Anbieterdienst weiterhin existiert. Das Regelwerk sollte portabel genug sein, um dort zu laufen, wo die Organisation es kontrolliert, und explizit genug, dass die Wechselkosten niedrig bleiben.
Deshalb ist Open Source auch hier wichtig. Eine Regel-Engine, die an Compliance, Zugriff, Preisgestaltung oder Betrug beteiligt ist, ist keine dekorative Abhängigkeit. Sie ist Teil der Kontrollebene. Wenn niemand innerhalb der Organisation sie prüfen, festlegen, testen und pflegen kann, dann gehört das Regelwerk nicht wirklich ihnen. Es ist gemietete Autorität.
Was vor der Einführung zu prüfen ist
Erstens: Identifizieren Sie die Entscheidungspunkte. Beginnen Sie nicht mit einer Plattformmigration. Beginnen Sie mit einem Regelwerk, das heute wehtut. Wie oft läuft es? Was schützt es? Wer fragt nach dem Warum? Was passiert, wenn der Dienst ausfällt? Welche Belege sind sechs Monate später verfügbar?
Zweitens: Prüfen Sie die Form der Regeln. Sind die Einschränkungen boolesch, arithmetisch, linear, ganzzahlig, endlich-dimensional, pfadartig oder weich? Welche Backend-Klasse sollte sie besitzen? Wenn die Regel nicht erklären kann, warum sie zu einer Solver-Familie weiterleitet, ist die Abstraktion zu magisch.
Drittens: Prüfen Sie die Artefakt-Disziplin. Wo wird die Quellregel gespeichert? Welcher Build hat das Artefakt erzeugt? Welche Prüfsumme wurde geladen? Welche Anwendungsversion hat es verwendet? Welche Eingaben wurden protokolliert? Welcher Wiedergabepfad beweist die Antwort? Wenn die Antwort über drei Systeme und eine Person namens Jan verteilt ist, ist das Regelwerk noch kein Prüfobjekt. Es ist eine Tradition.
Die Lektion
Lattice ist eine Geschichte über eine Regel-Engine, aber eigentlich ist es eine Geschichte über Kontrolle. Kompilieren Sie das Regelwerk vor der Anfrage. Packen Sie es in ein Artefakt, das die Anwendung per mmap nutzen kann. Prüfen Sie das Artefakt, bevor Sie es laden. Leiten Sie Einschränkungen an die richtige Solver-Familie weiter. Führen Sie im Prozess aus. Spielen Sie später mit derselben Eingabe und derselben Regelwerkversion erneut ab.
Das ist nicht glamourös. Gut. Geschäftsregeln sollten nicht glamourös sein. Sie sollten langweilig, schnell, explizit und überprüfbar sein. Die wichtigen Entscheidungssysteme in einem Unternehmen sollten nicht von entfernten Orakeln, Parser-Schleifen und Audit-Archäologie abhängen. Sie sollten ihre Regelwerke wie Infrastruktur mit sich führen.
Das Regelwerk sollte kein entferntes Orakel sein. Es sollte etwas sein, das das System ausführen, benennen und erneut abspielen kann.