Regeln als Daten

COADF P-8, wie veröffentlicht: Die Regeln, an denen eine Entscheidung gemessen wird, sind Daten, die Engine, die sie auswertet, ändert sich nicht, wenn sich eine Regel ändert, und ein Entscheidungssatz ist an die Version des Regelwerks gebunden, die ihn erzeugt hat, was die Spur aus P-4 in die Herkunft der Regeln hinein verlängert. COADF benennt den Stand der Technik selbst: Regelwerke, die sich neu laden lassen, mit Entscheidungssätzen, die mit ihrer Version verknüpft sind, gibt es bereits, und Open Policy Agent ist das naheliegende Beispiel.

COADF hält einen Teil von P-8 zurück und sagt das auf seiner Seite zu den Prinzipien. Nichts auf dieser Seite beschreibt diesen Teil. Die Beispiele verwenden einen bewusst generischen Gegenstand: welche Features eine Deployment-Umgebung aktivieren darf.

Regeln ändern sich häufiger als Code, und aus anderen Gründen: eine Leitlinie einer Aufsichtsbehörde, ein Vertrag, ein neuer Markt. Lebt eine Regel im Code, ist jede Änderung ein Release, mehrere Dienste driften auseinander, und niemand kann sagen, welche Version einer Regel eine Entscheidung aus dem letzten Quartal erzeugt hat.

Das letzte Problem ist das teure. Eine Entscheidung, die sich nicht rekonstruieren lässt, lässt sich nicht erklären, und eine Entscheidung, die sich nicht erklären lässt, lässt sich nicht verteidigen.

Die Form ist klein: Die Anwendung fragt über eine Schnittstelle an, die ihr gehört, die Schnittstelle zieht versioniertes Policy-Material heran, und die zurückkommende Entscheidung trägt die Revision dieses Materials.

• Eine Policy-Schnittstelle, die der Anwendung gehört. Die Anwendung stellt eine Frage in ihren eigenen Begriffen, und die Engine sitzt hinter einem Adapter.
• Versioniertes Policy-Material. Regeln und ihre Daten sind Artefakte mit einer Kennung pro Revision, unabhängig von der Anwendung deployt.
• Die Revision an jeder Entscheidung. Der Entscheidungssatz trägt die Antwort, die Revision und genug von der Eingabe, um sie erneut auszuführen.
• Alte Revisionen bleiben abrufbar. Eine erneute Ausführung braucht das Material, wie es war, nicht wie es ist.
• Reproduzierbare Auswertung. Eine Policy, die während der Auswertung Daten abruft oder die Uhr liest, lässt sich nicht allein aus ihrer Eingabe und ihrer Revision erneut ausführen. Solche Fakten werden als Eingabe übergeben und festgehalten.
• Auch die Engine versioniert. Ein Upgrade der Engine kann Bedeutung ändern: OPA 1.0 hat die Schlüsselwörter if und contains zur Pflicht gemacht, zum Beispiel. Die Version der Engine wird überall festgehalten, wo es auf erneute Ausführung ankommt.
• Kontrolliertes Scheitern. Eine unbekannte Revision, eine fehlende Revision, eine fehlerhafte Antwort oder eine nicht erreichbare Engine erzeugt ein Ergebnis, das die für die Regel verantwortliche Stelle vorab gewählt hat, nie einen nicht festgehaltenen Standardwert. Eine allgemeingültige richtige Antwort gibt es nicht: Die Aktion zu verweigern ist richtig für eine Regel zum Feature-Zugriff wie im Beispiel des Python-Profils; für eine andere Entscheidung legt die verantwortliche Stelle fest, was Scheitern bedeutet, und hält die Wahl fest.

Technologieoptionen

• Open Policy Agent. Eine Policy-Engine für allgemeine Zwecke, die Policy-Entscheidungen von ihrer Durchsetzung entkoppelt, mit in Rego geschriebenen Policies. Ein Bundle kann ein Manifest mit einer Revision mitführen, und die Decision Logs von OPA halten für jede Entscheidung die verwendete Bundle-Revision fest. Seine REST-API liefert eine decision_id, wenn Decision Logging aktiviert ist.
• Regeltabellen, die der Anwendung gehören. Zeilen mit einer Revision und einem Geltungszeitraum, ausgewertet von Code, der sich nicht ändert, wenn sich die Zeilen ändern.
• Entscheidungstabellen und DMN, wo die Verantwortlichen für die Regeln Analystinnen und Analysten statt Entwicklerinnen und Entwickler sind.
• Andere Policy-Sprachen und Engines. OPA ist hier ein Beispiel. COADF setzt es nicht voraus.

• Regeln im Code, mit der Build-Revision an jeder Entscheidung. Für ein kleines System gangbar. Jede Regeländerung ist dann ein Release, und die Engine ändert sich mit jeder Regel, was P-8 ausschließt.
• Feature-Flag-Dienste. Policy-ähnlich und oft ohne Herkunft der Entscheidung: Welche Flag-Konfiguration eine bestimmte Anfrage beantwortet hat, wird häufig nicht festgehalten.
• Ein Entscheidungsdienst, der einem anderen Team gehört, über dieselbe Schnittstelle genutzt, mit der Revision in seiner Antwort.

• Das Muster liefert Herkunft, nicht Korrektheit. Eine sauber versionierte falsche Regel bleibt falsch.
• Es deckt weder die Teile von P-8 ab, die COADF nicht veröffentlicht, noch, wie eine Policy-Entscheidung mit irgendeiner anderen Kontrolle zusammentrifft.
• Open Policy Agent ist eine Beispiel-Engine. Nichts hier macht sie zur Voraussetzung.