Lösungsansatz

Es gibt drei Gruppen von Services:

Services, um Produktwissen abzurufen: Produkteigenschaften, zulässige Konfigurationen und Regeln.
Services, um Prozesswissen abzurufen: welche der in der Norm zulässigen Prozessvarianten eine Versicherung umsetzt.
Services, um Geschäftsobjekte (Berechnungen, Offerte, Anträge, Verträge, Änderungsanträge, Schadenmeldungen) zu erzeugen, zu bearbeiten und durch ihre Zustände zu führen.

Die heutigen OMDS-3-Services der Antragsstrecke setzen voraus, dass der Client Prozess- und Produktwissen einprogrammiert hat. Die neuen Services stellen diese Informationen zur Laufzeit zur Verfügung.

Alle Services sind eine von sechs Operationsarten: Die ersten beiden Gruppen sind Auskünfte – sie lesen oder rechnen und bewahren nichts beim Versicherer auf –, die dritte Gruppe erzeugt ein Geschäftsobjekt, leitet es aus einem Vorgänger ab, ersetzt oder bearbeitet seinen Inhalt oder wechselt mit einem Übergang seinen fachlichen Zustand. Für alle Arten gelten dieselben vier Prüfungen in derselben Reihenfolge, und alle Geschäftsfalltypen – Antragsstrecke, Vertragsänderung, Konvertierung, Schadenmeldung – werden mit denselben Arten bedient. Das Modell beschreibt Geschäftsobjekte und Operationen; diese Seite nennt nur, was daraus für die Schnittstelle und das Produktwissen folgt.

Schnittstellentechnik

Die Fachlichkeit wird als Knowledge-Graph in JSON-LD übertragen; Vokabular und Constraints sind in RDFS/OWL und SHACL beschrieben. Eine Einführung in diese Technologien geben die Technischen Grundlagen.
Die Services sind in OpenAPI definiert.
Die KI-Schnittstelle ist ein MCP-Server vor den OpenAPI-Services.
Antworten enthalten Hypermedia-Links auf die zulässigen Folgeschritte, am Geschäftsfall und an jedem seiner Geschäftsobjekte: welche Bearbeitungen, Übergänge und Ableitungen jetzt erlaubt sind. Ein Client – ob programmiert, Smart-Client oder KI-Agent – muss den Ablauf nicht aus der Dokumentation kennen, sondern liest ihn aus der Antwort ab. Was dort nicht steht, ist nicht zulässig.
Alle Operationen antworten in derselben Form: das betroffene Geschäftsobjekt vollständig, sein Zustand, der Prüfbericht, die fachlichen Ergebnisse des Versicherers (Prämie, Entscheidung, Meldungen) und die Folgeschritte.

Anforderungen an die Services

Semantische Schemas: Datenfelder sind selbsterklärend mit Typen, Beschreibungen und Beispielen semantisch annotiert.
MCP-Kompatibilität: Die Kernfunktionen stehen als standardisierte Tools für das Model Context Protocol zur Verfügung.
Schrittweise Vorvalidierung: Schnelle Teilprüfungen (z. B. Fahrzeug- oder Vorversicherungsdaten) sind direkt während des Dialogs möglich. Sie sind ein Angebot an den Client, keine Pflicht: Die Versicherung führt alle Prüfungen in jedem Fall selbst aus.
Fehler-Feedback und Next-Best-Action: Fehlermeldungen enthalten klare Handlungsanweisungen, die ein Modell direkt in Kundenrückfragen umwandeln kann. Jede Antwort weist die zulässigen Folgeschritte und die dafür benötigten Pflichtfelder explizit aus.
Idempotenz und Freigabe-Gate: Doppelabschlüsse werden zuverlässig verhindert. Der Übergang „einreichen“ des Antrags erfordert ein explizites Bestätigungs-Token als Parameter (Human-in-the-Loop).

Produktwissen

Das Produktmodell wird deklarativ als Knowledge-Graph beschrieben (siehe Produkt und Produktbaum und Versicherungsprodukte als Regelwerke). Die Berechnung bleibt bei der Versicherung. Der Client kann eine Konfiguration aber mit den mitgelieferten SHACL-Constraints vor dem Absenden selbst prüfen und so unnötige Roundtrips vermeiden.

Verpflichtend ist diese Vorprüfung nicht. Eine Versicherung muss weder alle Prüfungen an den Client übertragen noch darf sie sich darauf verlassen, dass der Client geprüft hat: Sie führt alle Prüfungen selbst aus, bei jeder Anfrage. Deshalb kann jede Antwort Meldungen enthalten, an jedem Instanzknoten und jedem Attribut, und ein Element kann mehrere Meldungen zugleich tragen. Ein Client muss sie je Element anzeigen können, auch wenn er dieselbe Prüfung selbst hätte ausführen können.

Was aus einer Verletzung folgt, hängt davon ab, welche der vier Prüfungen sie betrifft; sie laufen bei jeder Operation in derselben Reihenfolge:

Zulässigkeit (Zustand des Geschäftsobjekts, Rechte des Aufrufers): Eine unzulässige Operation – einreichen auf einem schon eingereichten Antrag, bearbeiten eines übergebenen Objekts – wird abgelehnt und ändert nichts.
Konformität (Baustein zulässig, Attribut gehört zum Knoten, Wert im Wertebereich, Parameter passen): Eine nicht konforme Operation wird mit Prüfbericht abgelehnt und ändert nichts. Ein gespeichertes Geschäftsobjekt ist deshalb immer konform.
Vollständigkeit (Pflichtangaben, die der Zustand verlangt): Beim Erzeugen, Ableiten, Ersetzen und Bearbeiten ist sie keine Bedingung – auch ein unvollständiges Objekt wird gespeichert, der Server erkennt ihm den Zustand Entwurf zu, die Antwort listet, was fehlt, und nennt die Folgeschritte, die deshalb noch nicht möglich sind. Ist das Objekt gültig, erkennt er den Zustand Bereit zu (beim Antrag einreichbar, beim Offert annehmbar, bei der Berechnung berechenbar). Ein Übergang (berechnen, annehmen, einreichen) setzt Vollständigkeit voraus und wird sonst abgelehnt, ohne etwas zu ändern.
Fachliche Prüfung der Versicherung (Prämie, Annahmerichtlinien, Deckung, Plausibilitäten): liefert ein Ergebnis und Meldungen am betroffenen Element, kein Ja oder Nein über die Struktur.

Ein Client macht das sichtbar: das Geschäftsobjekt, seinen zuerkannten Zustand (Entwurf oder Bereit), was noch fehlt, und welche Folgeschritte die Versicherung gerade anbietet.

Entwurf und Bearbeitung (Delta-Operationen)

Hält die Versicherung ein Geschäftsobjekt als Entwurf selbst – sie deklariert das als Prozesswissen für das Geschäftsobjekt, heute die Berechnung („Entwurf am Server“) –, muss ein Client nicht bei jeder Änderung das ganze Objekt senden (Ersetzung), sondern kann es mit kleinen Operationen verändern (Bearbeitung). Er erzeugt das Geschäftsobjekt mit dem gewählten Produkt und dem Stichtag – damit entsteht der Geschäftsfall – und erhält den Entwurf als Default-Instanz: das Verkaufsprodukt, seine Pflichtbausteine und jedes Attribut mit seiner Vorbelegung. Danach bearbeitet er den Entwurf mit den Delta-Operationen: addComponent schließt einen Baustein des Produkts an einem Knoten des Entwurfs ein – samt seinen Pflichtbausteinen und seinen Attributen in Vorbelegung –, removeComponent schließt einen eingeschlossenen Baustein mit seinem Teilbaum wieder aus, setAttributeValue setzt oder löscht den Wert eines Attributs; createRiskObject, assignRiskObject und removeRiskObject legen Risikoobjekte an, ordnen sie Bausteinen zu und entfernen sie wieder (siehe Risikoobjekte). Weitere Bearbeitungen für Personen und Antragsfragen folgen demselben Muster.

Jede Antwort ist das vollständige Geschäftsobjekt, nicht nur der geänderte Teil, und trägt drei Dinge, mit denen der Client ohne eigenes Zustandsmodell weiterarbeitet:

den Prüfbericht über das ganze Objekt (Pflichtbausteine, Pflichtattribute, Wertebereiche) mit Meldungen je Knoten und Attribut – auch ein unvollständiges Objekt wird gespeichert und so gemeldet – und den daraus zuerkannten Zustand, Entwurf oder Bereit;
das Produktwissen zur Instanz: an jedem Knoten, welche Bausteine dort noch eingeschlossen werden können, wie oft und ob das gerade zulässig ist; an jedem Attribut die zulässigen Werte;
die Folgeschritte: welche Bearbeitungen auf welchem Knoten jetzt erlaubt sind, und am Geschäftsobjekt, ob der Übergang – bei der Berechnung „berechnen“ – jetzt zulässig ist. Was dort nicht steht, ist nicht zulässig.

Eine nicht konforme Bearbeitung – der Baustein gehört nicht unter diesen Knoten, die Höchstanzahl ist erreicht, der Knoten existiert nicht – wird abgelehnt und ändert nichts; die Antwort nennt den Grund maschinenlesbar. Das Ausschließen eines Pflichtbausteins ist dagegen eine konforme Bearbeitung: Das Objekt wird unvollständig, fällt in den Zustand Entwurf zurück, der Bericht sagt, was fehlt, und der Übergang „berechnen“ ist bis dahin kein Folgeschritt. So lässt sich ein Pflichtbaustein gegen einen anderen tauschen, ohne einen widersprüchlichen Zwischenzustand zu erfinden. Ebenso wird ein Attributwert außerhalb des zulässigen Bereichs gespeichert und am Attribut gemeldet; abgelehnt wird nur ein Wert, der nicht zum Datentyp des Attributs passt.

Der Muster-Vermittler zeigt das Muster: Deklariert die Versicherung „Entwurf am Server“, baut er den Produktbaum nach jeder Antwort neu aus dem Entwurf – eingeschlossene Bausteine als Zeilen, die noch einschließbaren mit „“ –, aktiviert „“, „−“ und „Berechnen“ nur, wenn die Folgeschritte die Operation nennen, und zeigt eine Ablehnung als Meldung am betroffenen Baustein. „Berechnen“ nennt dabei nur den Geschäftsfall: Die Versicherung berechnet den Entwurf, den sie selbst hält, und antwortet mit der Prämie je Baustein, die bis zur nächsten Änderung sichtbar bleibt. Ohne die Deklaration hält er die Konfiguration wie bisher lokal und sendet sie vollständig zur Berechnung. Ein KI-Agent arbeitet mit denselben Antworten: Folgeschritte sagen ihm, welches Werkzeug er als Nächstes aufrufen darf, das Produktwissen zur Instanz, womit, und der Bericht, was noch fehlt.

Clients mit und ohne Vorwissen

Die Norm erlaubt zwei Arten von Clients, die dieselben Produkte bedienen:

Ein Client mit Vorwissen lädt das Produktwissen vorab – Produktbaum, Häufigkeiten, Attribute mit Datentyp, Grenzen und Vorbelegung –, baut die Konfiguration selbst und sendet sie zur Berechnung vollständig; die Versicherung prüft sie dann. Was das Produktwissen deklariert – Mindestanzahl der Bausteine und Risikoobjekte, Pflichtattribute, Grenzen und Datentypen –, kann er schon vorher selbst prüfen und mit denselben Meldungen zeigen wie die Versicherung; verbindlich ist deren Prüfung bei der Berechnung. Das passt zu Clients, die ein Produkt fachlich kennen, und funktioniert auch ohne „Entwurf am Server“.
Ein Client ohne Vorwissen kennt nur die Basis-URL der Versicherung, das gewählte Produkt, den Stichtag und die Namen der Operationen. Alles Weitere entnimmt er der jeweils letzten Antwort: wie die Bausteine heißen, welche an welchem Knoten noch eingeschlossen werden dürfen, welche Pflicht sind, welche Attribute es gibt und welche Werte zulässig sind, was noch fehlt und welche Folgeschritte jetzt möglich sind. Er setzt „Entwurf am Server“ voraus, ändert das Geschäftsobjekt in kleinen Bearbeitungen und baut seine Eingabefelder aus den zulässigen Werten eines Attributs (Datentyp, Grenzen, Pflicht, Vorbelegung).

Welche Art ein Client bei einer Versicherung nutzen kann, sagt ihm deren Deklaration des Prozesswissens. Der Muster-Vermittler enthält beide: den Produktbaum-Konfigurator mit Vorwissen und den Entwurfs-Editor ohne Vorwissen, der zusätzlich jeden Aufruf mit Request und Antwort zeigt. Ein KI-Agent ist der typische Client ohne Vorwissen.

Die Referenzimplementierung setzt heute die Antragsstrecke bis zur Berechnung um, folgt dabei aber noch nicht dem Modell der Geschäftsobjekte: Die Berechnung antwortet wie eine Tarifauskunft, legt aber zugleich ein Objekt unter einer Geschäftsfall-ID an, und der Entwurfsstatus steht am Geschäftsfall. Die Umstellung auf Auskunft, Erzeugung und zuerkannte Zustände am Geschäftsobjekt ist der nächste Schritt (Vorgehen).

Geschäftsfall und Folgeschritte

Ein Geschäftsfall ist die Klammer, unter der die Geschäftsobjekte eines Vorgangs liegen – in der Antragsstrecke Berechnung, Offert, Antrag und Vertrag. Er hat selbst keinen fachlichen Zustand; den tragen die Geschäftsobjekte, als zuerkannten Zustand aus dem Inhalt (Entwurf, Bereit) oder als gesetzten Zustand aus einer Handlung (eingereicht, in Prüfung, Rückfrage, angenommen, abgelehnt). Der Geschäftsfall trägt, was die Versicherung als Prozesswissen über ihn deklariert – ob sie ihn aufbewahrt, wer darauf zugreifen darf, ob Dritte ihn gemeinsam bearbeiten –, und er liefert mit jeder Antwort die Folgeschritte an sich und an seinen Objekten. Wie Geschäftsobjekte entstehen (Erzeugung, Ableitung), wie sie ihre Zustände wechseln (Übergang) und welche Geschäftsfalltypen es gibt, beschreibt Geschäftsobjekte und Operationen; die Antragsstrecke als erstes Beispiel Antragsstrecke.

Prozesswissen

Prozesswissen ist analog zum Produktwissen gelagert: Die Norm zählt die zulässigen Prozessvarianten abschließend auf, jede Versicherung deklariert maschinenlesbar, welche sie umsetzt, und der Client stellt sich zur Laufzeit darauf ein. Wo eine Variante deutlich überwiegt, ist sie Regelfall; deklariert wird dann nur die Abweichung.

Die Deklaration erfolgt je Geschäftsfalltyp: welche Geschäftsobjekte, Übergänge und Ableitungen es gibt, wer sie anstoßen darf, welche Parameter ein Übergang erwartet (etwa das Bestätigungs-Token beim Einreichen), welche Eingaben ein Zustand verlangt, ab wann ein Geschäftsfall persistiert und gemeinsam bearbeitbar ist und ob die Versicherung Entwürfe hält. Die Antragsstrecke ist die erste normierte Deklaration; Vertragsänderung, Konvertierung und Schadenmeldung folgen im selben Raster (Geschäftsfalltypen).

Konformität

Versicherungen müssen prüfen können, ob ihre Services der Norm entsprechen. Eine Auswertung zeigt, ob alles normgerecht unterstützt wird oder wo Defizite bestehen. Ebenso müssen Vermittler prüfen können, ob ihr Client alle Features der Norm unterstützt. Nur dann kann sich eine Versicherung darauf verlassen, ein Produkt automatisch auszurollen. Die Profile der Norm beschreibt Profile der Norm, die Prüfwerkzeuge Werkzeuge.