Werkzeuge

Eine Norm ohne Werkzeuge wird nicht umgesetzt, sondern interpretiert – und dann divergieren die Implementierungen. Die Werkzeuge sind daher Teil der Norm und kein nachgelagertes Projekt.

Grundsätze

  • Die Arbeitsgruppe erstellt die Werkzeuge selbst, mit KI-Unterstützung.

  • Werkzeuge werden kontinuierlich gemeinsam mit der Norm entwickelt und veröffentlicht. Eine Normversion ist kein Dokument, sondern ein Release aus Spezifikation und Werkzeugen.

  • Als Vorbild dient HL7 FHIR: Implementation Guide als Website, Validator als Bibliothek und CLI, öffentliche Referenzserver, Konformitätssuiten, Konformitätsregister.

  • Selbsttest, Zertifizierung und Entwickler-Validator nutzen dieselbe Prüflogik. „Lokal grün, Zertifizierung rot“ zerstört das Vertrauen in die Werkzeuge.

  • Vorhandenes wird genutzt, nicht nachgebaut. SHACL-Engines, OpenAPI-Generatoren und BPMN-Werkzeuge sind verfügbar. Die Kapazität der Arbeitsgruppe gehört in die Norm, die Konformitätssuite und die Produktmodell-Werkzeuge.

Muster-Versicherung, MCP-Server, Dokumentationswebseite und die Selbsttests (siehe Vorgehen) sind bereits Werkzeuge in diesem Sinne. Die folgende Aufstellung ergänzt sie und ist nicht als Reihenfolge zu lesen, da die Werkzeuge begleitend entstehen.

Für die Arbeitsgruppe

OpenAPI, JSON-LD-Context, SHACL-Shapes und BPMN-Modelle beschreiben dieselbe Fachlichkeit. Von Hand gepflegt divergieren sie.

  • Eine Quelle der Wahrheit mit Generierung: Die OpenAPI-Schemas werden aus den SHACL-Shapes erzeugt oder beide aus einer gemeinsamen Beschreibung. Ersatzweise Doppelpflege mit Kreuzvalidierung in der CI.

  • Norm-Linter in der CI: Jede im BPMN referenzierte Operation existiert in OpenAPI, jede SHACL-Shape hat einen JSON-LD-Term, Namenskonventionen und Pflichtlabels sind eingehalten.

  • Prüfung der Prozessvarianten in der CI: Jede zulässige Variante ist im BPMN modelliert, hat einen Term im Prozesswissen-Vokabular und ist durch Beispielinstanzen abgedeckt.

  • Maschinenlesbarer Normdiff zwischen zwei Normversionen, damit Versicherungen ihre Releases planen können.

  • Kanonische Beispielinstanzen je Use-Case, in der CI gegen SHACL und OpenAPI validiert. Sie dienen zugleich als Dokumentation, Testfixture und Grundlage für KI-Agenten.

  • Entscheidungsprotokoll der Arbeitsgruppe, damit Entscheidungen im Steuerkreis nachvollziehbar sind und nicht mehrfach neu verhandelt werden.

Für Entwickler

  • Validator als Bibliothek und CLI: Instanz hinein, Konformitätsurteil mit präziser Fehlermeldung heraus.

  • Muster-Versicherung und Muster-Vermittler als Container mit vorbefüllten Daten. Ein Vermittlerentwickler muss ohne Versicherung arbeiten können und umgekehrt.

  • Muster-Versicherung in allen zulässigen Prozessvarianten konfigurierbar. Ein Client muss auch gegen eine Versicherung getestet werden können, die den Antragsentwurf nicht am Server hält.

  • Offizielle SDKs für Java, .NET und TypeScript. Generiert jeder Implementierer selbst, entstehen viele Varianten.

  • Testdatengenerator aus den SHACL-Shapes, der valide und absichtlich invalide Instanzen erzeugt.

  • Mock-Versicherung, die aus einem Produktmodell erzeugt wird. Das ist möglich, weil Produktwissen deklarativ vorliegt.

Für Versicherungen

  • Selbsttest mit Konformitätsbericht, der die erfüllten Profile ausweist und die Lücken auflistet. Lauffähig in der CI der Versicherung und als Weboberfläche für nicht-technische Nutzung.

  • Abgleich von Deklaration und Verhalten: Der Selbsttest prüft, ob sich eine Versicherung so verhält, wie sie ihr Prozesswissen deklariert. Eine falsche Deklaration ist für Clients schädlicher als eine fehlende.

  • Öffentliches Konformitätsregister: welche Versicherung erfüllt welche Profile, welche Sparten, welche Normversion und welche Prozessvarianten.

  • Gap-Analyse für den Wrapper: Aus WSDL und Produkt ergibt sich, welche Operationen des Basisprofils bedienbar sind.

  • Regressionsprüfung für Produktmodelle: Bricht eine Produktänderung bestehende Clients?

Für die Autorierung von Produktwissen

Produktverantwortliche in Versicherungen schreiben kein OWL und kein SHACL. Ohne Werkzeuge für diesen Schritt erreicht niemand das Profil Produktwissen, und das Kernziel des Projektes wird nicht erreicht. Diese Gruppe von Werkzeugen trägt daher das höchste Projektrisiko.

  • Konverter, der aus bestehender Produktdokumentation und Tarifunterlagen einen Entwurf des Produktmodells erzeugt.

  • Validator, der ein Produktmodell auf Wohlgeformtheit und Vollständigkeit prüft.

  • Simulator, der zeigt, welche Konfigurationen ein Produktmodell zulässt, damit Produktverantwortliche ohne Entwickler prüfen können, ob das Modell ihr Produkt trifft.

Für KI-Agenten

  • MCP-Server für die Norm selbst, nicht nur für die Services, damit ein Agent die Spezifikation während der Implementierung abfragen kann.

  • Maschinenlesbarer Dokumentationsindex auf der Normwebsite.

  • Agenten-Benchmark: Schafft ein unveränderter KI-Agent, der nur die veröffentlichten Artefakte erhält, einen Kfz-Antrag von Ende zu Ende gegen die Muster-Versicherung? Das ist die messbare Form des Ziels, dass die Services einfach mit KI-Hilfe angebunden werden können.

Priorisierung

  1. Validator mit gemeinsamer Prüflogik, weil alles andere darauf aufbaut.

  2. Sandbox-Container beider Seiten, weil sie die Einstiegshürde am stärksten senken.

  3. Quelle der Wahrheit für die Normartefakte, weil Divergenz später kaum zu beheben ist.

  4. Konformitätssuite und Register, weil sie Konformität sichtbar und vergleichbar machen.

  5. Werkzeuge zur Autorierung von Produktwissen, weil sie über das Profil Produktwissen entscheiden.

  6. Agenten-Benchmark, weil er das Kernziel messbar macht.

Die Punkte 3 und 5 sind vor der Fertigstellung der Schnittstellendefinition anzugehen, da beide später nur teuer nachzuholen sind.