Glossar

Am Zug (engl. actor): Eine der drei Rollen an jedem → Geschäftsobjekt: wer als Nächstes handeln muss – Kunde, Vermittler, Versicherer oder Dritter. Ändert sich mit dem Zustand: am Entwurf und in der Rückfrage der Vermittler, am eingereichten Antrag der Versicherer, beim offenen → Nebenprozess der Kunde oder der Dritte. Die anderen beiden Rollen sind → Veranlasser und → Verantwortlicher (siehe Kernmerkmale jedes Geschäftsobjekts).

A priori: Vorab und unabhängig vom konkreten Fall festgelegt. Umschreibung der → Produktdefinition, kein eigener Begriff der Norm (siehe Versicherungsprodukte als Regelwerke).

Ableitung (engl. derivation): → Operationsart, die ein neues → Geschäftsobjekt aus einem Vorgänger anlegt und dessen IRI als Herkunft am neuen Objekt einträgt – Offert aus Berechnung, Antrag aus Offert, Vertrag aus Antrag. Der Vorgänger bleibt unverändert; die Herkunft ist ein Verweis, keine feste Bindung. Übermittelt wird entweder das ganze neue Objekt mit Verweis auf den Vorgänger (OMDS-3-Stil) oder nur das Delta dazu (Delta-Ableitung). Anstoßen darf sie, wer für das neue Objekt verantwortlich ist: der Vermittler bis zum Antrag, der Versicherer für den Vertrag. Führt zum nächsten Objekt; der → Übergang wechselt dagegen den Zustand desselben Objekts (siehe Geschäftsobjekte und Operationen).

Antrag: Ein konkretes Angebot eines Kunden an den Versicherer, einen Versicherungsvertrag zu den konfigurierten Bedingungen abzuschließen. Ausprägung einer → Produktkonfiguration, erweitert um → Antragsfragen und Personen. → Geschäftsobjekt der → Antragsstrecke mit den zuerkannten Zuständen Entwurf und einreichbar und den gesetzten Zuständen eingereicht, in Prüfung, Rückfrage, angenommen, abgelehnt; der Vertrag entsteht aus ihm durch → Ableitung des Versicherers.

Antragsfragen: Felder im Antrag, die das Produkt in Beziehung zur Realität setzen, ohne die Prämie zu beeinflussen (z. B. Personendaten, IBAN, Bezugsrechte). Sie sind nicht Teil von Produktkonfiguration oder Berechnung, sondern erst von Antrag und Vertrag (siehe Antragsfragen).

Antragsstrecke: Der Ablauf von der Produktauswahl über Konfiguration und Berechnung bis zur Einreichung des Antrags (siehe Antragsstrecke). Erster → Geschäftsfalltyp der Norm, umgesetzt und erprobt; seine Geschäftsobjekte sind Berechnung, Offert, Antrag und Vertrag, in der Sparte Kfz zusätzlich die → Versicherungsbestätigung.

Attribut: → Produktattribut bzw. → Instanzattribut.

Auskunft (engl. inquiry): → Operationsart ohne → Geschäftsobjekt: Tarifauskunft zu einer Konfiguration, Produktwissen, verfügbare Produkte, Prozesswissen. Liest oder rechnet, bewahrt nichts beim Versicherer auf und ist beliebig wiederholbar. Eine anonyme → Berechnung ist eine Auskunft; erst wenn der Versicherer sie aufbewahrt (→ Erzeugung), wird sie zum Geschäftsobjekt (siehe Geschäftsobjekte und Operationen).

Bearbeitung (engl. edit): → Operationsart, die den Inhalt eines → Geschäftsobjekts in einem Schritt verändert, ohne das ganze Objekt zu senden: Baustein einschließen oder ausschließen, Attributwert setzen, Risikoobjekt anlegen oder zuordnen, Beleg hinzufügen – die bisherigen → Delta-Operationen. Setzt voraus, dass der Versicherer das Objekt als → Entwurf hält. Antwort ist immer das vollständige Objekt; der Server erkennt danach den → zuerkannten Zustand neu zu. Gegenstück mit ganzem Objekt: → Ersetzung (siehe Geschäftsobjekte und Operationen).

Beispielkatalog der Norm: Kleiner, informativer Produktkatalog, mit dem die Norm ausgeliefert wird (Namensraum ex:, Ordner examples/products/sample/ im Modul standard-definition): eine Kfz-Versicherung mit Pflicht- und Wahlbausteinen, Attributen aller vier Typen, Häufigkeiten und einer Vorgängerbeziehung, eine Lebensversicherung ohne Baustein, dazu Beispielinstanzen. Gehört keinem → Beispielversicherer und keiner → Muster-Versicherung; die Prüfregeln der Norm werden gegen ihn getestet. Siehe Produktbaum und Instanzbaum.

Beispielversicherer : "Disrupto Digital Risk Ventures European SE": Fiktives Hypergrowth-InsurTech mit Tischkicker und Barista-Flatrate. Macht prinzipiell alles gaaanz anders als die trägen Althäuser: Produkte werden vollautomatisiert im Minutentakt „neu erfunden“, Features noch im Commit auf Produktion getestet und die eigenen Mitarbeiter blicken bei den Deckungen längst nicht mehr durch – aber egal, Hauptsache der Exit rückt näher. Seine Produkte (Kfz, Leben) dienen als informative Anschauungsbeispiele, Testdaten der Referenzimplementierungen und als vorbefüllter Produktkatalog der → Muster-Versicherung (Datenmodul reference/example-insurers). Namensraum dis:; siehe Beispielversicherer.

Beispielversicherer : "Anglo-American a. G. gegr. 1859": Fiktives, traditionsreiches Bestandshaus mit jahrzehntelanger Historie und gewachsenen Systemwelten. Hier wird Gründlichkeit großgeschrieben: Tarifänderungen reifen über Jahre, Anträge werden strukturiert verarbeitet, und Neuerungen der Norm werden gerne pragmatisch über einen → Wrapper angebunden. Dient als Gegenpol zur "Disrupto" zur Veranschaulichung stabiler Bestandsarchitekturen und Abwärtskompatibilität. Namensraum aa:; siehe Beispielversicherer.

Beispielversicherer : "Pfefferminzia Versicherungs-AG": Fiktiver mittelgroßer Kompositversicherer – der Regelfall am Markt, weder InsurTech noch Bestandshaus. Solide Produkte, pragmatische Prozesse, der günstigste Tarif der drei. Dient als dritter Versicherer, damit der → Muster-Vermittler das Zusammenspiel mit mehreren Versicherungen vorführen kann. Namensraum pfm:; siehe Beispielversicherer.

Berechnungsmethode : Die Formel, mit der die Muster-Versicherung die Prämie eines Produkts berechnet. Der Tarif eines → Beispielversicherers ordnet jedem Produkt seines Katalogs genau eine Berechnungsmethode zu (heute „Kfz“ und „Leben“); die Eingaben einer Methode sind im → Produktwissen als Attribute deklariert. Kein Teil der Norm; siehe Beispielversicherer.

Berechnung: Ausprägung einer → Produktkonfiguration, für die die Versicherung die Prämie ermittelt. Die Berechnung selbst bleibt immer bei der Versicherung. Anonym ist sie eine → Auskunft; bewahrt der Versicherer sie auf, ist sie das erste → Geschäftsobjekt der → Antragsstrecke (zuerkannter Zustand berechenbar, Übergang berechnen) und begründet einen → Geschäftsfall.

Bereit (engl. ready): Allgemeiner Name des → zuerkannten Zustands, in dem ein → Geschäftsobjekt → gültig ist und der zustandsabhängige → Übergang unter den → Folgeschritt-Links steht. Je Objekttyp heißt er anders: berechenbar bei der Berechnung, annehmbar beim Offert, einreichbar beim Antrag, meldbar bei der Schadenmeldung. Gegenstück: → Entwurf (siehe Geschäftsobjekte und Operationen).

BPMN (Business Process Model and Notation): Standardnotation für Geschäftsprozesse. Darin werden die normierten Prozesse und → Prozessvarianten für Menschen dargestellt – eine Darstellungsform der Schichten der Norm in der → Prozesssäule, kein → Träger.

Domänenereignis (engl. domain event): Eintrag in der Historie eines → Geschäftsobjekts: Zeitpunkt, → Operationsart, handelnder Akteur, Versionskennung und ein Ereignisname aus dem Vokabular des Geschäftsfalltyps (bct:ApplicationSubmitted, bct:SubprocessFulfilled). Die → Auskunft „Zustandsänderungen abrufen“ liefert die Ereignisse aller Objekte eines → Geschäftsfalls seit einem Zeitpunkt, auch der → untergeordneten Geschäftsobjekte.

Deckungsbaum (Produktbaum): Die hierarchische Struktur eines Versicherungsprodukts aus → Produktknoten. Definiert, welche Bausteine, Deckungen und Optionen verfügbar sind und wie sie kombiniert werden können. Er ist das gemeinsame Rückgrat von Produktkonfiguration, Berechnung, Offert, Antrag und Vertrag.

Default-Instanz: Vorschlag einer → Produktinstanz, den der Server zu einem gewählten Produkt erzeugt und den der Client weiter konfiguriert.

Delta-Operation (engl. delta operation): Operation, die einen → Entwurf in einem Schritt verändert, statt die ganze Produktinstanz zu senden – addComponent schließt einen Baustein ein, removeComponent schließt ihn aus; weitere für Attributwerte und Risikoobjekte folgen. Antwort ist immer der vollständige Entwurf mit Prüfbericht, → Produktwissen zur Instanz und → Folgeschritt-Links; nur möglich, wenn die Versicherung „Entwurf am Server“ als → Prozesswissen deklariert (siehe Lösungsansatz). Im Modell der → Operationsarten ist jede Delta-Operation eine → Bearbeitung.

Entwurf (engl. draft): Ein → Geschäftsobjekt, das der Versicherer hält und das schrittweise aufgebaut wird – heute die Produktkonfiguration einer Berechnung, später auch Offert, Antrag, Änderungsantrag oder Schadenmeldung. Zugleich der → zuerkannte Zustand eines Geschäftsobjekts, das → konform, aber noch → unvollständig ist; jede Antwort meldet, was fehlt. Sobald es → gültig ist, erkennt der Server ihm den Zustand → Bereit zu. Eine nicht konforme → Bearbeitung oder → Ersetzung wird abgelehnt und ändert nichts. Ob ein Versicherer Entwürfe hält („Entwurf am Server“), deklariert er als → Prozesswissen.

Erzeugung (engl. creation): → Operationsart, die ein neues → Geschäftsobjekt ohne Vorgänger anlegt; der Client übermittelt das ganze Objekt – Berechnung aufbewahren, Offert oder Antrag direkt anlegen, Schaden melden. Hat der Client noch keinen → Geschäftsfall, entsteht er mit der Erzeugung. Gegenstück mit Vorgänger: → Ableitung (siehe Geschäftsobjekte und Operationen).

Ersetzung (engl. replacement): → Operationsart, die den Inhalt eines → Geschäftsobjekts durch ein ganzes neu übermitteltes Objekt ersetzt (Update im OMDS-3-Stil). Der Server prüft den neuen Inhalt und erkennt den → zuerkannten Zustand danach neu zu. Gegenstück mit Delta: → Bearbeitung (siehe Geschäftsobjekte und Operationen).

Fahrzeugvorlage (engl. vehicle template): Gängiger Fahrzeugtyp mit Marke, Type, Leistung und Listenpreis im Katalog eines Versicherers (risk:VehicleTemplate). Ein Vorschlag für das Fahrzeugformular: Die Wahl füllt Marke, Type, Leistung und Listenpreis vor, die Felder bleiben bearbeitbar; das Fahrzeug verweist nicht auf die Vorlage. Wissen des Versicherers, nicht der Norm (siehe Fahrzeugvorlagen des Versicherers).

FIBO (Financial Industry Business Ontology): Eine branchenübergreifende Ontologie für die Finanzindustrie, die präzise Definitionen für Finanz- und Vertragsbegriffe liefert. Keine → Schicht des Vokabulars der Norm: geprüft und nicht eingeführt; bei Bedarf werden Begriffe der Norm per rdfs:subClassOf darauf abgebildet.

Folgeschritt-Links (engl. next-step links): Teil jeder Antwort; nennen die im aktuellen Zustand zulässigen Operationen (OpenAPI-operationId, zugleich Name des MCP-Tools), die Zielressource und die SHACL-Shape der erwarteten Daten (bc:expects). Sie hängen am → Geschäftsfall und an seinen → Geschäftsobjekten und nennen → Bearbeitungen, → Übergänge und → Ableitungen, die jetzt zulässig sind; der zustandsabhängige Übergang steht nur bei einem → gültigen Objekt (Zustand → Bereit). Was dort nicht steht, ist nicht zulässig. Umsetzung von → HATEOAS und → Next-Best-Action ohne eigenes Hypermedia-Vokabular.

Freigabe-Gate: Explizite Bestätigung durch einen Menschen (Human-in-the-Loop) per Bestätigungs-Token, bevor ein Antrag endgültig eingereicht wird. Schützt zusammen mit Idempotenz vor Doppelabschlüssen.

Geschäftsfall (engl. business case): Die Klammer, unter der zusammengehörige → Geschäftsobjekte liegen – in der Antragsstrecke Berechnungen, Offerte, Antrag und Vertrag eines Vorgangs. Entspricht der Geschäftsfallnummer in OMDS 3; ersetzt den früheren Begriff „Session“. Er trägt Persistenz, Berechtigung und gemeinsame Bearbeitung (als → Prozesswissen deklariert) und liefert die → Folgeschritt-Links, hat aber selbst keine fachlichen Zustände: die leben an den Geschäftsobjekten. Je → Geschäftsobjekttyp enthält er höchstens ein aktuelles → Hauptobjekt, frühere Stände als Versionen in seiner Historie; die Hauptobjekte der verschiedenen Typen bilden eine Kette mit Herkunft, und das jüngste Glied trägt die Folgeschritte. Unter einem Hauptobjekt können mehrere → untergeordnete Geschäftsobjekte liegen. Welche Typen in welcher Zahl vorkommen, deklariert der Geschäftsfalltyp. Jeder Geschäftsfall gehört zu genau einem → Geschäftsfalltyp. Regelfall: anonyme Berechnung ohne Geschäftsfall (→ Auskunft), ab dem ersten aufbewahrten Objekt persistiert (siehe Geschäftsobjekte und Operationen).

Geschäftsfalltyp (engl. business case type): Legt fest, welche → Geschäftsobjekte ein → Geschäftsfall tragen kann, welche Zustände, → Bearbeitungen, → Übergänge und → Ableitungen es gibt und wer sie anstoßen darf. Die Norm beginnt mit vier Typen: → Antragsstrecke (umgesetzt), → Vertragsänderung, → Konvertierung und → Schadenmeldung und -bearbeitung. Die Deklaration je Typ ist → Prozesswissen (siehe Geschäftsobjekte und Operationen).

Geschäftsobjekt (engl. business object): Das, was der Versicherer aufbewahrt und was sich verändern lässt: Berechnung, Offert, Antrag, Vertrag, Änderungsantrag, Schadenmeldung. Hat eine eigene IRI unter dem → Geschäftsfall, einen Inhalt und einen fachlichen Zustand (→ zuerkannter Zustand, → gesetzter Zustand). Entsteht durch → Erzeugung oder → Ableitung, wird durch → Bearbeitung oder → Ersetzung verändert und durch einen → Übergang dem Versicherer übergeben; danach ist es für den Client unveränderlich. Jedes Geschäftsobjekt trägt dieselben Kernmerkmale: Zeitstempel, Version, Begründung zum Zustand, die drei Rollen → Veranlasser, → Verantwortlicher und → am Zug, Frist und Folge, Historie aus → Domänenereignissen, Verweis auf seine Deklaration und → Navigationslinks. Ein Geschäftsobjekt ist → Hauptobjekt oder → untergeordnetes Geschäftsobjekt (siehe Geschäftsobjekte und Operationen).

Gesetzter Zustand (engl. set state): Zustand eines → Geschäftsobjekts, der aus einer Handlung folgt, nicht aus dem Inhalt: durch einen → Übergang des Clients (eingereicht, angenommen, gemeldet) oder durch den Versicherer in seiner Bearbeitung (in Prüfung, Rückfrage, angenommen, abgelehnt). Gegenstück: → zuerkannter Zustand.

Gültig (engl. valid): → konform und → vollständig. Erst ein gültiges → Geschäftsobjekt hat den zustandsabhängigen → Übergang unter seinen → Folgeschritt-Links: bei der Berechnung „berechenbar“, beim Offert „annehmbar“, beim Antrag „einreichbar“. Diese Wörter bezeichnen den → zuerkannten Zustand → Bereit je Objekttyp.

Hauptobjekt (engl. main object): → Geschäftsobjekt, das direkt unter dem → Geschäftsfall liegt und → untergeordnete Geschäftsobjekte tragen kann: in der → Antragsstrecke Berechnung, Offert, Antrag und Vertrag. Je Typ gibt es im Geschäftsfall höchstens ein aktuelles Hauptobjekt.

Haftpflicht (Kfz-Haftpflicht): Pflichtversicherung für Schäden, die mit dem Fahrzeug Dritten zugefügt werden.

HATEOAS (Hypermedia as the Engine of Application State): Architekturprinzip für REST-APIs: Der Client navigiert, indem er den Links folgt, die der Server abhängig vom aktuellen Zustand in den Antworten liefert. In diesem Projekt weisen solche Links die zulässigen Folgeschritte aus (→ Next-Best-Action).

Hydra: Ein Vokabular auf Basis von JSON-LD, um Hypermedia-gesteuerte Web-APIs zu beschreiben. Wird in dieser Norm nicht verwendet: Folgeschritte werden als → Folgeschritt-Links auf OpenAPI-Operationen ausgewiesen.

Instanz (i:Instance): Wurzel eines Instanzbaums; die konkrete Instanz eines → Produkts, auf das sie per i:basedOn verweist. Dieselbe Instanz wird in Produktkonfiguration, Berechnung, Offert, Antrag und Vertrag verwendet und dort um die Angaben des jeweiligen Geschäftsobjekts erweitert. Konkrete Unterklasse von → Instanzknoten (siehe Produktbaum und Instanzbaum).

Instanzattribut (i:InstanceAttribute): Ausprägung eines → Produktattributs in einer Produktinstanz; verweist per i:basedOn auf das Produktattribut und trägt höchstens einen Wert (i:value) im Datentyp seiner Attributklasse.

Instanzbaum: Die hierarchische Struktur einer → Produktinstanz aus → Instanzknoten; Gegenstück zum → Deckungsbaum (siehe Produktbaum und Instanzbaum).

Instanzknoten (i:InstanceNode): Abstrakter Oberbegriff für → Instanz und → Instanzkomponente; jeder Knoten eines Instanzbaums. Verweist per i:basedOn auf den → Produktknoten, auf dem er beruht, und trägt Komponenten und Instanzattribute. Kommt nie selbst vor, sondern nur als Instanz oder Instanzkomponente (siehe Produktbaum und Instanzbaum).

Instanzkomponente (i:InstanceComponent): Knoten einer Produktinstanz unterhalb der Wurzel; verweist per i:basedOn auf eine → Produktkomponente und hat genau einen Elternknoten. Konkrete Unterklasse von → Instanzknoten.

JSON-LD (JavaScript Object Notation for Linked Data): Ein leichtgewichtiges Format für Linked Data. Es ermöglicht, strukturierte Daten so zu vernetzen, dass sie von Maschinen und KI-Agenten semantisch verstanden werden. Austauschformat der Fachlichkeit in diesem Projekt.

Kasko (Teilkasko, Vollkasko): Versicherung von Schäden am eigenen Fahrzeug. Die Teilkasko deckt Schäden ohne Zutun des Lenkers (z. B. Diebstahl, Glasbruch, Naturgewalten), die Vollkasko zusätzlich selbst verschuldete Unfallschäden und Vandalismus.

Konform (engl. conforming): Ein → Geschäftsobjekt oder das Ergebnis einer beantragten Änderung erfüllt das Produktmodell – Typen, Kardinalitäten, Wertebereiche, Struktur des → Produktbaums – und die Anfrage ist syntaktisch richtig. Eine nicht konforme (non-conforming) Operation wird abgelehnt und ändert nichts; das gilt für alle → Operationsarten, auch für den → Übergang und seine Parameter. Ein gespeichertes Objekt ist daher immer konform. Zweite der vier Prüfungen, nach der Zulässigkeit und vor → vollständig.

Konvertierung: Ablöse eines bestehenden Vertrags durch einen neuen Vertrag auf einem aktuellen Produkt. → Geschäftsfalltyp (eigener Typ, nicht Variante der → Vertragsänderung): bestehender Vertrag → Konvertierungsantrag (→ Ableitung durch den Vermittler) → neuer Vertrag (Ableitung durch den Versicherer, immer). Welche Produkte infrage kommen, ist eine → Auskunft zum bestehenden Vertrag.

MCP (Model Context Protocol): Standardprotokoll, über das KI-Assistenten Werkzeuge (Tools) aufrufen. Der MCP-Server ist die KI-Schnittstelle vor den OpenAPI-Services.

Meldung: Hinweis, Warnung oder Fehler zu einem Element einer Produktkonfiguration, z. B. aus einer → Plausi oder einer Validierung. Soll eine Handlungsanweisung für die Korrektur enthalten. Hängt am betroffenen Instanzknoten oder Attribut; ein Element kann mehrere Meldungen tragen. Kommt immer von der Versicherung, auch wenn der Client dieselbe Prüfung ausführen kann.

Muster-Versicherung: Referenzimplementierung der Services auf Seite der Versicherung (Modul reference/sample-insurer).

Muster-Vermittler: Referenzimplementierung eines Clients auf Seite des Vermittlers (Modul reference/sample-broker).

Navigationslink (engl. navigation link): Verweis an einem → Geschäftsobjekt, wohin ein Client von dort kommen kann, mit einer Standardrelation der IANA: up (Geschäftsfall bzw. Hauptobjekt), collection und item (untergeordnete Objekte), predecessor-version, successor-version, version-history, latest-version (Historie), related (Herkunft), describedby (Deklaration bzw. Produktdefinition), profile (Profil der Norm). Gegenstück zu den → Folgeschritt-Links, die sagen, was ein Client tun kann. Hypermedia-Form der typisierten Verweise, ohne eigene Hülle wie → Hydra (siehe Kernmerkmale jedes Geschäftsobjekts).

Nebenprozess (engl. subprocess, bc:Subprocess): → Untergeordnetes Geschäftsobjekt, das einen Vorgang bei Kunde, Vermittler, Versicherer oder Drittem im → Geschäftsfall vertritt: Rabattabzeichnung, Genehmigungsvorbehalt/Annahme, Attest, Vorschadenbesichtigung, Personenidentifikation, Zulassung. Hat Art, fachliche Kennung, Ergebnis, Frist und Folge, ist blockierend oder nicht und wird vor oder nach der Einreichung zusammengeführt. Zuerkannte Zustände offen und ungültig, gesetzte Zustände erfüllt, abgelehnt, abgebrochen, abgelaufen. Ein blockierender offener Nebenprozess sperrt den → Übergang „einreichen“ des Hauptobjekts über die → Folgeschritt-Links und die → Vollständigkeit (siehe Nebenprozesse).

Next-Best-Action: Anforderung, dass jede Antwort die zulässigen Folgeschritte und die dafür benötigten Pflichtfelder ausweist, sodass Client oder KI-Agent den nächsten Schritt ohne Dokumentation bestimmen können.

Offert: Angebot der Versicherung zu einer berechneten → Produktkonfiguration mit Gültigkeitsdauer und Prämienbindung. → Geschäftsobjekt der → Antragsstrecke zwischen Berechnung und Antrag (zuerkannter Zustand annehmbar, Übergang annehmen); entsteht durch → Ableitung aus einer Berechnung oder durch → Erzeugung ohne sie.

OMDS (Oesterreichischer Makler Datenstandard): Ein Branchenstandard in Österreich für den Austausch von Versicherungsdaten. OMDS 3 definiert die Services zwischen Vermittler und Versicherung (bisher als SOAP mit WSDL/XSD).

OMDS LD (OMDS Linked Data): Arbeitstitel dieses Vorhabens: Überarbeitung von OMDS 3 mit OpenAPI, JSON-LD, SHACL, BPMN und MCP, Produkt- und Prozesswissen zur Laufzeit. Ob und unter welchem Namen daraus eine Norm wird (etwa OMDS 4), entscheidet der Steuerkreis.

Ontologie: Formale Beschreibung von Begriffen und ihren Beziehungen (hier in RDFS/OWL), z. B. was ein Produktknoten oder eine Instanzkomponente ist. Zusammen mit den → Shapes bildet sie den normativen Kern der Norm.

OpenAPI: Standard zur Beschreibung von HTTP-APIs (Operationen, Pfade, Datenstrukturen). Normative Beschreibung der Services in diesem Projekt.

Operationsart (engl. operation kind): Eine der sechs Arten, auf die sich alle Operationen der Norm zurückführen lassen, geordnet nach zwei Achsen – was übermittelt wird (ganzes Objekt oder Delta) und was sich ändert (nichts, neues Objekt, Inhalt, fachlicher Zustand): → Auskunft, → Erzeugung, → Ableitung, → Ersetzung, → Bearbeitung, → Übergang. Für alle gelten dieselben vier Prüfungen in derselben Reihenfolge: Zulässigkeit, → Konformität, → Vollständigkeit, fachliche Prüfung des Versicherers (siehe Geschäftsobjekte und Operationen).

Plausi (Plausibilitätsprüfung): Regel, die eine Produktkonfiguration auf fachliche Stimmigkeit prüft, z. B. dass nicht gleichzeitig Voll- und Teilkasko eingeschlossen sind. Ergebnis ist eine → Meldung.

Prämie: Preis des Versicherungsschutzes; wird von der Versicherung aus einer Produktkonfiguration berechnet.

Produkt (p:Product): Wurzelelement des Deckungsbaums, entspricht dem OMDS-3-Verkaufsprodukt. Als Regelwerk definiert es a priori, welche Produktkonfigurationen zulässig sind. Konkrete Unterklasse von → Produktknoten (siehe Produktbaum und Instanzbaum).

Produktattribut (p:ProductAttribute): Eigenschaft eines Produktknotens mit Typ, Vorbelegung, Wertebereich und Pflichtkennzeichen (z. B. Versicherungssumme, Selbstbehalt).

Produktbaustein, Produktkomponente (p:ProductComponent): Knoten des Deckungsbaums unterhalb des Produkts, etwa Haftpflicht oder Vollkasko. Legt über minimale und maximale Häufigkeit fest, ob sie Pflicht oder optional ist. OMDS 3 benennt die Ebenen unterschiedlich; die Norm unterscheidet nur Produkt und Produktkomponente. Konkrete Unterklasse von → Produktknoten.

Produktdefinition (p:): Die für alle Kunden gleiche, vorab (a priori) festgelegte Beschreibung eines Produkts: Deckungsbaum, Kardinalitäten, Attribute mit Wertebereichen und Regeln (Products.ttl, produktspezifische SHACL-Shapes). Wird von Produktverantwortlichen der Versicherung erstellt und im → Profil Produktwissen zur Laufzeit abrufbar gemacht. Eine der beiden Formen von → Produktwissen; Gegenstück: → Produktwissen zur Instanz.

Produktinstanz (i:Instance mit i:InstanceComponent): Konkreter Instanzbaum, der per i:basedOn auf ein Produkt und seine Komponenten verweist. Jede Produktinstanz, die die Produktregeln erfüllt, ist eine → Produktkonfiguration.

Produktknoten (p:ProductNode): Abstrakter Oberbegriff für → Produkt und → Produktkomponente; jeder Knoten eines Deckungsbaums. Bündelt die gemeinsamen Eigenschaften (Name, Verfügbarkeit, Komponenten, Produktattribute, Versicherungsbedingungen). Kommt nie selbst vor, sondern nur als Produkt oder Produktkomponente; Gegenstück zum → Instanzknoten (siehe Produktbaum und Instanzbaum).

Produktkonfiguration: Abstrakter Oberbegriff über alle Instanzen, die die Produktregeln zulassen. Jede regelkonforme Produktinstanz ist eine Produktkonfiguration. Berechnung, Offert, Antrag und Vertrag sind konkrete Ausprägungen davon, die je nach Geschäftsobjekt um weitere Angaben erweitert werden (z. B. Antragsfragen, Personen, Zahlungsdetails). Die Produktkonfiguration beschreibt das gemeinsame, zugrundeliegende Modell; ob eine Instanz eine zulässige Produktkonfiguration ist, wird gegen die SHACL-Regeln des Produkts geprüft.

Produktwissen: Deklaratives, maschinenlesbares Wissen über Produkte; Kern des Profils Produktwissen (→ Profil; Repository-Name „ProductKnowledge“). Oberbegriff für zwei Formen: die → Produktdefinition (allgemein, für alle Kunden) und das → Produktwissen zur Instanz (auf eine konkrete Konfiguration angewandt). Wird zur Laufzeit übermittelt, damit Clients Konfigurationen selbst bilden und validieren können.

Produktwissen zur Instanz: Teil jeder Antwort im → Profil Produktwissen, die eine Instanz enthält: welche Komponenten an einem Knoten der Instanz einschließbar sind (mit Kardinalität und aktueller Anzahl) und welche Attributwerte zulässig sind. Aus → Produktdefinition und Instanz berechnet, ohne eigene Quelle; stimmt mit den produktspezifischen SHACL-Shapes überein. Im Basisprofil nicht enthalten – dort kennt der Client das Produkt selbst.

Profil: Abgegrenzter Leistungsumfang der Norm, dessen Erfüllung der → Selbsttest ausweist (siehe Profile der Norm). Das Profil Produktwissen baut auf dem Basisprofil auf:

Prozessvariante: Zulässiger Weg, einen Use-Case abzuwickeln (z. B. Antragsentwurf am Server speichern oder nicht). Die Norm zählt die Varianten abschließend auf; eine überwiegende Variante ist → Regelfall.

Prozesssäule (engl. process pillar): Die Säule des Vokabulars, die das „Wie“ beschreibt: → Geschäftsfall, → Geschäftsfalltyp, → Geschäftsobjekt mit → zuerkannten und → gesetzten Zuständen, → Operationsarten, → Übergänge, → Ableitungen, → Folgeschritt-Links, → Prozessvarianten und → Prozesswissen. Fünf Schichten; Geschäftsprozess-Kern (bc:), Vokabular der Deklaration (pk:) und Geschäftsfalltypen (bct:) liegen in den Grundlagen, die Prozessvarianten der Norm in der landesspezifischen Normierung (atpv:), die Deklaration je Versicherer in der Schicht Versicherer. Gegenstück: → Struktursäule (siehe Schichten des Vokabulars, Geschäftsobjekte und Operationen).

Prozesswissen: Maschinenlesbare Deklaration einer Versicherung, welche der zulässigen → Prozessvarianten sie umsetzt. Wird zur Laufzeit abgefragt. Teil des → Basisprofils; in OMDS 3 nicht vorhanden. Schicht Versicherer der → Prozesssäule.

Referenz-Wrapper: Die → Muster-Versicherung mit SOAP-Adapter, die jede normative Operation beider → Profile über die bestehenden SOAP-Services demonstriert; Nachweis der Wrapperfähigkeit.

Regelfall: Prozessvariante, die die Norm als Normalfall festlegt, weil sie deutlich überwiegt. Deklariert wird nur die Abweichung; Clients müssen dennoch alle zulässigen Varianten bedienen.

Risikoobjekt (Versichertes Interesse): Der Gegenstand oder die Person, auf die sich das versicherte Risiko bezieht (z. B. ein Kfz, ein Gebäude, eine Person in der Lebensversicherung). Alle Risikoobjekte sind von einem abstrakten Basis-Risikoobjekt abgeleitet und tragen die Risikomerkmale; eine Instanz führt sie als Liste, Bausteine verweisen gerichtet auf sie (siehe Risikoobjekte). Risikoobjekte sind Teil der Produktkonfiguration; ihre Risikoparameter bestimmen maßgeblich die Prämie.

Risikoparameter: Prämienrelevante Eigenschaften, die alle Risikoeigenschaften eines Falls bündeln (z. B. Geburtsdatum, Leistung eines Kfz). Sie ermöglichen Berechnungen ohne die konkreten Antragsfragen.

Schadenmeldung und -bearbeitung (engl. claim notification and claims handling): → Geschäftsfalltyp, der mit einer → Erzeugung beginnt (Schadenmeldung mit Bezug auf den Vertrag), nicht mit einer Ableitung. Prüfung, Rückfrage und Regulierung sind → gesetzte Zustände bzw. → Ableitungen des Versicherers; Belege kommen als → Bearbeitung hinzu, auch in der Rückfrage. Geplant; außerhalb des heutigen Umfangs der Referenzimplementierungen.

Schema.org: Ein offenes Vokabular zur Strukturierung von Daten im Web. Dient als allgemeine semantische Basis (Upper Ontology) für Dinge wie Personen oder Organisationen.

Schichten des Vokabulars (engl. vocabulary layers): Die fünf Stufen der Allgemeinheit, die jede Säule des Vokabulars durchläuft – Allgemein (externe Vokabulare wie Schema.org), Grundlagen (Grundbegriffe und Prinzipien für alle Märkte, z. B. die Metamodelle für Produkt und Geschäftsprozess), Norm Europa (was aus europäischem Recht und europäischen Standards für alle europäischen Märkte gilt; derzeit nicht belegt), Landesspezifische Normierung (z. B. Österreich) (was OMDS LD für einen einzelnen Landesmarkt festlegt, z. B. Prozessvarianten und Codelisten aus OMDS 3) und Versicherer (je Versicherer deklariert oder ergänzt). Grundlagen, Norm Europa und landesspezifische Normierung bauen aufeinander auf. Jede Schicht besteht aus → Vokabularen; die Schicht eines Begriffs ergibt sich aus seinem Vokabular. Zwei Säulen: → Struktursäule und → Prozesssäule; quer dazu die → Träger (siehe Schichten des Vokabulars). Nicht zu verwechseln mit den → Profilen der Norm.

Selbsttest: Werkzeug, mit dem eine Versicherung bzw. ein Vermittler prüft, ob die eigene Implementierung der Norm entspricht; weist die erfüllten → Profile und die Lücken aus.

SHACL (Shapes Constraint Language): W3C-Spezifikation zur Validierung von RDF-Graphen (wie JSON-LD). Wird genutzt, um Produktregeln, Pflichtfelder und Kardinalitäten formal und maschinenlesbar zu definieren.

Shape: Einzelne SHACL-Regel bzw. Regelgruppe, z. B. „ein Produktknoten muss einen Namen haben“.

Sparte: Versicherungszweig, z. B. Kfz, Leben oder Sach. Die Norm beginnt mit der Sparte Kfz.

Stichtag: Datum, zu dem die Verfügbarkeit von Produkten bestimmt wird (gegen p:availableFrom/p:availableUntil).

Struktursäule (engl. structural pillar): Die Säule des Vokabulars, die das „Was“ beschreibt: → Produkt, → Produktkomponente, → Produktattribut, → Produktinstanz, Personen und Rollen, Vertragsdaten, Codelisten und die → Shapes dazu. Fünf Schichten: Schema.org (schema:); in den Grundlagen Produktdefinition und Produktinstanz (p:, i:), Risikoobjekte (risk:), Vertragsdaten und Rollen (ct:) und je Sparte ein Vokabular (z. B. motor:); je Sparte ein Vokabular in Norm Europa und in der landesspezifischen Normierung (z. B. atmotor:), dort auch die österreichischen Fachbegriffe (at:) und die Abbildung auf OMDS 3 (omds:); Produktkataloge und Ergänzungen je Versicherer. Gegenstück: → Prozesssäule (siehe Schichten des Vokabulars, Produktbaum und Instanzbaum).

Träger (engl. carrier): Technisches Mittel, über das die beiden Säulen des Vokabulars den Client erreichen und ausgeführt werden – keine → Schicht des Vokabulars: → JSON-LD und → SHACL-Shapes für die → Struktursäule, → OpenAPI, → MCP-Werkzeuge und → Folgeschritt-Links für die → Prozesssäule (siehe Schichten des Vokabulars).

Untergeordnetes Geschäftsobjekt (engl. subordinate business object, bc:parent): → Geschäftsobjekt, das einem → Hauptobjekt desselben → Geschäftsfalls untergeordnet ist. Hat IRI, Inhalt, Art, eigenen Lebenszyklus und eigene Version wie jedes Geschäftsobjekt und ist ein eigenes Aggregat; die Regel „je Typ ein aktuelles Objekt“ gilt für es nicht, die Anzahl deklariert der → Geschäftsfalltyp. Eine Änderung des Hauptobjekts kann es ungültig machen; sein Zustand geht in die → Vollständigkeit des Hauptobjekts ein. Wandert bei der → Ableitung des Hauptobjekts mit, soweit deklariert. Erste Art: → Nebenprozess (siehe Untergeordnete Geschäftsobjekte).

Übergang (engl. transition): → Operationsart, die den fachlichen Zustand desselben → Geschäftsobjekts wechselt: Antrag einreichen, Offert annehmen, Rückfrage abschließen. Eigene Syntax, optional parametrisierbar (z. B. Bestätigungs-Token des → Freigabe-Gates), aber ohne Inhalt des Objekts; nur im passenden Zustand und nur bei → gültigem Objekt zulässig, sonst abgelehnt, ohne etwas zu ändern. Danach ist das Objekt in der Hand des Versicherers und für den Client unveränderlich. Führt nicht zum nächsten Objekt; das tut die → Ableitung (siehe Geschäftsobjekte und Operationen).

Veranlasser (engl. requester): Eine der drei Rollen an jedem → Geschäftsobjekt: wer das Objekt hat entstehen lassen – der Vermittler für Berechnung, Offert und Antrag, der Versicherer für den Vertrag und die von ihm angeforderten → Nebenprozesse. Wird bei der Entstehung gesetzt. Die anderen beiden Rollen sind → Verantwortlicher und → am Zug.

Verantwortlicher (engl. owner): Eine der drei Rollen an jedem → Geschäftsobjekt: wer über Zustand und Ergebnis entscheidet – in der Regel der Versicherer, am Entwurf der Vermittler. Wird bei der Entstehung gesetzt. Die anderen beiden Rollen sind → Veranlasser und → am Zug.

Verkaufsprodukt: OMDS-3-Bezeichnung für das Wurzelelement eines Produkts; entspricht → Produkt.

Vermittler: Makler oder Agent, der Versicherungsprodukte vergleicht, Anträge einreicht und Verträge betreut.

Vertrag: Abgeschlossene Vereinbarung zwischen Versicherungsnehmer und Versicherung; Ausprägung einer → Produktkonfiguration nach Annahme des Antrags. → Geschäftsobjekt, das nur durch → Ableitung des Versicherers aus einem Antrag entsteht (die einzige verpflichtende Ableitung der → Antragsstrecke) und das Vertragsänderung, Konvertierung und Schadenmeldung als Bezug nennen.

Versicherungsbestätigung (engl. insurance confirmation; Kfz: VB): Bestätigung des Versicherers, die der Kunde für die Zulassung des Fahrzeugs vorlegt, bevor der Vertrag besteht. → Geschäftsobjekt der → Antragsstrecke in der Sparte Kfz, das der Versicherer durch → Ableitung aus dem Antrag anlegt; welche Zustände sie hat und ob sie auch ohne Antrag erzeugt werden darf, deklariert das → Prozesswissen (siehe Zustandsdiagramm Kfz).

Vertragsänderung: Änderung eines bestehenden Vertrags, z. B. Kfz-Wechsel oder Anpassung der Deckung. → Geschäftsfalltyp: bestehender Vertrag → Änderungsantrag (→ Ableitung durch den Vermittler) → geänderter Vertrag (Ableitung durch den Versicherer, immer). Es gibt kein „Änderungsangebot“ als eigenes Objekt; Prämie und Folgen der Änderung sind Ergebnisse am Änderungsantrag.

Verweisregel (engl. risk object rule): Angabe des Produktwissens an einem Produktknoten, auf welche Art von → Risikoobjekten seine Bausteine verweisen, wie viele eigene Verweise sie haben und ob die Ziele unter den Risikoobjekten des Elternbausteins liegen müssen (p:riskObjectRule). Ein Baustein ohne Verweisregel hat keinen eigenen Verweis; für ihn gelten die Risikoobjekte des Elternbausteins (siehe Risikoobjekte).

VN (Versicherungsnehmer): Die Person oder Organisation, die den Vertrag mit dem Versicherer schließt und in der Regel die Prämie schuldet.

Vokabular (engl. vocabulary): Zusammengehörige Begriffe mit einem eigenen Namespace, die genau einer → Schicht des Vokabulars angehören und genau einem Zweck dienen, z. B. die Risikoobjekte (risk:) oder die österreichischen Festlegungen der Sparte Kfz (atmotor:). Eine Schicht hat in der Regel mehrere Vokabulare.

Vollständig (engl. complete): Alle Pflichteingaben, die der aktuelle Zustand des → Geschäftsobjekts verlangt, sind vorhanden – Pflichtattribute mit Wert, Pflichtbausteine mit Risikoobjekt, Eingaben der Prämienberechnung, Antragsfragen. Welche Eingaben ein Zustand verlangt, deklariert das → Prozesswissen je → Geschäftsfalltyp. Bei → Erzeugung, → Ableitung, → Ersetzung und → Bearbeitung ist Vollständigkeit keine Bedingung: Ein unvollständiges (incomplete) Objekt wird gespeichert, der Prüfbericht nennt jede fehlende Eingabe am betroffenen Knoten, und der Server erkennt den Zustand → Entwurf zu. Beim → Übergang ist sie Voraussetzung. Dritte der vier Prüfungen.

Vorläufiger Wert (engl. provisional value, i:provisionalUntil): Wert eines → Instanzattributs, der vom Ergebnis eines → Geschäftsobjekts abhängt und bis dahin als vorläufig gekennzeichnet ist, mit Verweis auf dieses Objekt – meist einen → Nebenprozess, der zurück auf die betroffenen Bausteine zeigt. Erhöhter Selbstbehalt bis zur Vorschadenbesichtigung, vorläufige Deckung bis zur Annahme und Prämie bis zur Rabattabzeichnung sind Ausprägungen dieses einen Merkmals; die Werte stehen im Produktwissen, nicht im Nebenprozess.

VP (Versicherte Person): Die Person, auf deren Leben, Gesundheit oder Arbeitsfähigkeit sich der Versicherungsschutz bezieht. Muss nicht zwingend der Versicherungsnehmer sein.

Wrapper: Von einer Versicherung betriebene Komponente, die die neuen Services über ihre bestehenden SOAP-Services anbietet, ohne die Backendsysteme zu ändern: die → Muster-Versicherung mit einem SOAP-Adapter statt eines eigenen Tarifs. Vorne stellt er mit dem → Produktkatalog der Versicherung Entwurf, Delta-Operationen, Prüfbericht, → Produktwissen zur Instanz und → Folgeschritte bereit, hinten ruft er an den → Übergängen die SOAP-Services. Bei jeder Versicherung dieselbe Software, angepasst durch Deklaration, Katalog mit OMDS-Abbildung und Verbindung; mit leerem Katalog erfüllt er das → Basisprofil, mit Katalog das → Profil Produktwissen. Darf unbefristet betrieben werden. Siehe Abwärtskompatibilität.

Abweichungsschicht (engl. deviation layer): Südseite eines → Wrappers, in der als benannte Einträge mit Testfall und Ablaufdatum steht, was die SOAP-Implementierung einer Versicherung anders macht als OMDS 3; bei normgerechtem Endpunkt leer. Eine Abweichung ist entweder deklarierte Prozessvariante, Eintrag dieser Schicht oder Lücke im → Konformitätsregister; die Normseite des Wrappers bleibt bei jeder Versicherung gleich.

Zuerkannter Zustand (engl. assessed state): Zustand eines → Geschäftsobjekts, den der Server nach jeder Inhaltsänderung – → Bearbeitung wie → Ersetzung – aus dem Inhalt neu feststellt: → Entwurf, solange das Objekt → unvollständig ist, → Bereit (berechenbar, annehmbar, einreichbar, meldbar), sobald es → gültig ist. Lässt sich nicht setzen; eine Änderung kann ein bereites Objekt wieder zum Entwurf machen. Gegenstück: → gesetzter Zustand (siehe Geschäftsobjekte und Operationen).