Glossary

A priori (a priori): Defined in advance and independently of the specific case. A paraphrase of the → product definition, not a term of the standard (see Insurance Products as Rule Sets).

Actor (am Zug): One of the three roles at every → business object: who has to act next – customer, broker, insurer or third party. Changes with the state: at the draft and in the query the broker, at the submitted application the insurer, at an open → subprocess the customer or the third party. The other two roles are → requester and → owner (see Core Characteristics of Every Business Object).

Application (Antrag): A specific offer by a customer to the insurer to conclude an insurance contract on the configured terms. A form of a → product configuration, extended by → application questions and persons. → Business object of the → application process with the assessed states draft and submittable and the set states submitted, under review, query, accepted, rejected; the contract comes into being from it by → derivation of the insurer.

Application process (Antragsstrecke): The flow from product selection via configuration and calculation to the submission of the application (see Application Process). First → business case type of the standard, implemented and tried out; its business objects are calculation, offer, application and contract, in the motor line of business additionally the → insurance confirmation.

Application questions (Antragsfragen): Fields in the application that relate the product to reality without affecting the premium (e.g. personal data, IBAN, beneficiaries). They are not part of the product configuration or the calculation, only of application and contract (see Application Questions).

Approval gate (Freigabe-Gate): Explicit confirmation by a human (human in the loop) via a confirmation token before an application is finally submitted. Together with idempotency, it protects against duplicate contracts.

Assessed state (zuerkannter Zustand): State of a → business object that the server determines anew from the content after every change of content – → edit as well as → replacement: → draft as long as the object is → incomplete, → ready (calculable, acceptable, submittable, reportable) as soon as it is → valid. Cannot be set; a change can turn a ready object back into a draft. Counterpart: → set state (see Business Objects and Operations).

Attribute (Attribut): → product attribute or → instance attribute.

BPMN (Business Process Model and Notation): Standard notation for business processes. The standardised processes and → process variants are presented in it for humans – a form of presentation of the layers of the standard in the → process pillar, not a → carrier.

Broker (Vermittler): Broker or agent who compares insurance products, submits applications and services contracts. Used in this standard for every insurance intermediary.

Business case (Geschäftsfall): The bracket under which related → business objects lie – in the application process the calculations, offers, application and contract of one transaction. Corresponds to the business case number in OMDS 3; replaces the former term "session". It carries persistence, authorisation and joint editing (declared as → process knowledge) and provides the → next-step links, but has no business states of its own: those live at the business objects. Per → business object type it holds at most one current → main object, earlier states as versions in its history; the main objects of the different types form a chain with origin, and the youngest link carries the next steps. Under a main object several → subordinate business objects may lie. Which types occur in which number is declared by the business case type. Every business case belongs to exactly one → business case type. Default case: anonymous calculation without a business case (→ inquiry), persisted from the first kept object onwards (see Business Objects and Operations).

Business case type (Geschäftsfalltyp): Defines which → business objects a → business case can carry, which states, → edits, → transitions and → derivations exist and who may trigger them. The standard starts with four types: → application process (implemented), → contract change, → conversion and → claim notification and claims handling. The declaration per type is → process knowledge (see Business Objects and Operations).

Business object (Geschäftsobjekt): What the insurer keeps and what can be changed: calculation, offer, application, contract, contract change application, claim report. Has an IRI of its own below the → business case, a content and a business state (→ assessed state, → set state). Comes into being by → creation or → derivation, is changed by → edit or → replacement and handed over to the insurer by a → transition; after that it is immutable for the client. Every business object carries the same core characteristics: timestamps, version, state reason, the three roles → requester, → owner and → actor, deadline and consequence, history of → domain events, reference to its declaration and → navigation links. A business object is a → main object or a → subordinate business object (see Business Objects and Operations).

Carrier (Träger): Technical means through which the two pillars of the vocabulary reach the client and are executed – not a → vocabulary layer: → JSON-LD and → SHACL shapes for the → structural pillar, → OpenAPI, → MCP tools and → next-step links for the → process pillar (see Vocabulary Layers).

Calculation (Berechnung): A form of a → product configuration for which the insurer determines the premium. The calculation itself always remains with the insurer. Anonymous, it is an → inquiry; if the insurer keeps it, it is the first → business object of the → application process (assessed state calculable, transition calculate) and establishes a → business case.

Calculation method (Berechnungsmethode): The formula with which the sample insurer calculates the premium of a product. The tariff of an → example insurer assigns every product of its catalogue exactly one calculation method (today "motor" and "life"); the inputs of a method are declared as attributes in the → product knowledge. Not part of the standard; see Example Insurers.

Casco: partial casco, full casco (Kasko: Teilkasko, Vollkasko): Insurance of damage to one’s own vehicle. Partial casco covers damage not caused by the driver (e.g. theft, glass breakage, natural hazards); full casco also covers self-inflicted accident damage and vandalism.

Claim notification and claims handling (Schadenmeldung und -bearbeitung): → Business case type that begins with a → creation (claim report with reference to the contract), not with a derivation. Review, query and settlement are → set states or → derivations of the insurer; documents are added as → edits, also during a query. Planned; outside the current scope of the reference implementations.

Complete (vollständig): All mandatory inputs the current state of the → business object requires are present – mandatory attributes with a value, mandatory components with a risk object, the inputs of the premium calculation, application questions. Which inputs a state requires is declared as → process knowledge per → business case type. For → creation, → derivation, → replacement and → edit, completeness is not a condition: an incomplete (unvollständig) object is stored, the validation report names every missing input at the node concerned, and the server assesses the state → draft. For the → transition it is a prerequisite. Third of the four checks.

Conforming (konform): A → business object, or the result of a requested change, satisfies the product model – types, cardinalities, value ranges, structure of the → product tree – and the request is syntactically correct. A non-conforming operation is rejected and changes nothing; this applies to all → operation kinds, also to the → transition and its parameters. A stored object is therefore always conforming. Second of the four checks, after admissibility and before → complete.

Contract (Vertrag): Concluded agreement between policyholder and insurer; a form of a → product configuration after the application has been accepted. → Business object that comes into being only by → derivation of the insurer from an application (the only mandatory derivation of the → application process) and that contract change, conversion and claim notification name as reference.

Contract change (Vertragsänderung): Change to an existing contract, e.g. change of vehicle or adjustment of cover. → Business case type: existing contract → contract change application (→ derivation by the broker) → changed contract (derivation by the insurer, always). There is no "change offer" as an object of its own; premium and consequences of the change are results at the contract change application.

Conversion (Konvertierung): Replacement of an existing contract by a new contract based on a current product. → Business case type (type of its own, not a variant of the → contract change): existing contract → conversion application (→ derivation by the broker) → new contract (derivation by the insurer, always). Which products qualify is an → inquiry on the existing contract.

Coverage tree, product tree (Deckungsbaum, Produktbaum): The hierarchical structure of an insurance product made of → product nodes. Defines which components, covers and options are available and how they can be combined. It is the common backbone of product configuration, calculation, offer, application and contract.

Creation (Erzeugung): → Operation kind that sets up a new → business object without a predecessor; the client transmits the whole object – keep a calculation, set up an offer or application directly, report a claim. If the client has no → business case yet, it comes into being with the creation. Counterpart with predecessor: → derivation (see Business Objects and Operations).

Default case (Regelfall): Process variant that the standard defines as the normal case because it clearly predominates. Only the deviation is declared; clients must nevertheless support all permitted variants.

Default instance (Default-Instanz): Proposal of a → product instance that the server generates for a selected product and that the client configures further.

Delta operation (Delta-Operation): An operation that changes a → draft in one step instead of sending the whole product instance – addComponent includes a component, removeComponent excludes it; further ones for attribute values and risk objects follow. The response is always the complete draft with validation report, → product knowledge about the instance and → next-step links; only available where the insurer declares "draft at the server" as → process knowledge (see Solution Approach). In the model of the → operation kinds every delta operation is an → edit.

Derivation (Ableitung): → Operation kind that sets up a new → business object from a predecessor and records its IRI as origin at the new object – offer from calculation, application from offer, contract from application. The predecessor remains unchanged; the origin is a reference, not a fixed binding. Transmitted is either the whole new object with a reference to the predecessor (OMDS 3 style) or only the delta against it (delta derivation). It may be triggered by whoever is responsible for the new object: the broker up to the application, the insurer for the contract. Leads to the next object; the → transition, by contrast, changes the state of the same object (see Business Objects and Operations).

Domain event (Domänenereignis): Entry in the history of a → business object: point in time, → operation kind, acting party, version identifier and an event name from the vocabulary of the business case type (bct:ApplicationSubmitted, bct:SubprocessFulfilled). The → inquiry "fetch state changes" delivers the events of all objects of a → business case since a point in time, including the → subordinate business objects.

Draft (Entwurf): A → business object that the insurer holds and that is built up step by step – today the product configuration of a calculation, later also offer, application, contract change application or claim report. At the same time the → assessed state of a business object that is → conforming but still → incomplete; every response reports what is missing. As soon as it is → valid, the server assesses it as → ready. A non-conforming → edit or → replacement is rejected and changes nothing. Whether an insurer holds drafts ("draft at the server") is declared as → process knowledge.

Edit (Bearbeitung): → Operation kind that changes the content of a → business object in one step without sending the whole object: include or exclude a component, set an attribute value, set up or assign a risk object, add a document – the former → delta operations. Requires that the insurer holds the object as a → draft. The response is always the complete object; the server then assesses the → assessed state anew. Counterpart with the whole object: → replacement (see Business Objects and Operations).

Example insurer (Beispielversicherer): "Disrupto Digital Risk Ventures European SE": fictitious hypergrowth insurtech with table football and a barista flat rate. Does basically everything sooo differently from the sluggish incumbents: products are "reinvented" fully automatically every minute, features are tested in production while still being committed, and its own staff lost track of the covers long ago – but never mind, the exit is getting closer. Its products (motor, life) serve as informative illustrations, as test data of the reference implementations and as the pre-filled product catalogue of the → sample insurer (data module reference/example-insurers). Namespace dis:; see Example Insurers.

Example insurer (Beispielversicherer): "Anglo-American a. G. founded 1859": fictitious incumbent with a long tradition, decades of history and grown system landscapes. Thoroughness comes first here: tariff changes mature over years, applications are processed in a structured way, and innovations of the standard are pragmatically connected via a → wrapper. Serves as the counterpart to "Disrupto" to illustrate stable legacy architectures and backward compatibility. Namespace aa:; see Example Insurers.

Example insurer (Beispielversicherer): "Pfefferminzia Versicherungs-AG": fictitious mid-sized composite insurer – the typical case in the market, neither insurtech nor incumbent. Solid products, pragmatic processes, the cheapest tariff of the three. Serves as the third insurer so that the → sample broker can demonstrate the interplay with several insurers. Namespace pfm:; see Example Insurers.

FIBO (Financial Industry Business Ontology): A cross-industry ontology for the financial industry that provides precise definitions for financial and contractual terms. Not a → vocabulary layer of the standard: examined and not introduced; where needed, terms of the standard are mapped to it via rdfs:subClassOf.

HATEOAS (Hypermedia as the Engine of Application State): Architectural principle for REST APIs: the client navigates by following the links that the server returns depending on the current state. In this project, such links indicate the permitted next steps (→ next best action).

Hydra: A vocabulary based on JSON-LD for describing hypermedia-driven web APIs. Not used in this standard: next steps are indicated as → next-step links to OpenAPI operations.

Inquiry (Auskunft): → Operation kind without a → business object: tariff inquiry for a configuration, product knowledge, available products, process knowledge. Reads or calculates, keeps nothing with the insurer and can be repeated as often as desired. An anonymous → calculation is an inquiry; only when the insurer keeps it (→ creation) does it become a business object (see Business Objects and Operations).

Instance (Instanz, i:Instance): Root of an instance tree; the specific instance of a → product, to which it refers via i:basedOn. The same instance is used in product configuration, calculation, offer, application and contract, where it is extended by the information of the respective business object. Concrete subclass of → instance node (see Product Tree and Instance Tree).

Instance attribute (Instanzattribut, i:InstanceAttribute): Value of a → product attribute in a product instance; refers to the product attribute via i:basedOn and carries at most one value (i:value) in the datatype of its attribute class.

Instance component (Instanzkomponente, i:InstanceComponent): Node of a product instance below the root; refers to a → product component via i:basedOn and has exactly one parent node. Concrete subclass of → instance node.

Instance node (Instanzknoten, i:InstanceNode): Abstract generic term for → instance and → instance component; every node of an instance tree. Refers via i:basedOn to the → product node on which it is based and carries components and instance attributes. Never occurs itself, only as instance or instance component (see Product Tree and Instance Tree).

Instance tree (Instanzbaum): The hierarchical structure of a → product instance made of → instance nodes; counterpart of the → coverage tree (see Product Tree and Instance Tree).

Insurance confirmation (Versicherungsbestätigung; motor: VB): Confirmation by the insurer that the customer presents for the registration of the vehicle before the contract exists. → Business object of the → application process in the motor line of business that the insurer sets up by → derivation from the application; which states it has and whether it may also be created without an application is declared by the → process knowledge (see State Diagram Motor).

Insured person (VP, versicherte Person): The person whose life, health or ability to work is covered by the insurance. Does not necessarily have to be the policyholder.

JSON-LD (JavaScript Object Notation for Linked Data): A lightweight format for linked data. It allows structured data to be linked so that machines and AI agents understand it semantically. Exchange format of the business data in this project.

Line of business (Sparte): Branch of insurance, e.g. motor, life or property. The standard starts with motor.

Main object (Hauptobjekt): → Business object that lies directly under the → business case and can carry → subordinate business objects: in the → application process calculation, offer, application and contract. Per type there is at most one current main object in a business case.

MCP (Model Context Protocol): Standard protocol through which AI assistants call tools. The MCP server is the AI interface in front of the OpenAPI services.

Message (Meldung): Note, warning or error relating to an element of a product configuration, e.g. from a → plausibility check or a validation. Should contain instructions for correcting it. Attached to the affected instance node or attribute; one element can carry several messages. Always comes from the insurer, even where the client can run the same check.

Motor third-party liability (Haftpflicht, Kfz-Haftpflicht): Compulsory insurance for damage caused to third parties with the vehicle.

Navigation link (Navigationslink): Reference at a → business object stating where a client can go from there, with an IANA standard relation: up (business case or main object), collection and item (subordinate objects), predecessor-version, successor-version, version-history, latest-version (history), related (origin), describedby (declaration or product definition), profile (profile of the standard). Counterpart to the → next-step links, which say what a client can do. Hypermedia form of the typed references, without an envelope of its own such as → Hydra (see Core Characteristics of Every Business Object).

Next best action (Next-Best-Action): Requirement that every response states the permitted next steps and the mandatory fields they need, so that a client or AI agent can determine the next step without documentation.

Next-step links (Folgeschritt-Links): Part of every response; list the operations permitted in the current state (OpenAPI operationId, which is also the MCP tool name), the target resource and the SHACL shape of the expected data (bc:expects). They are attached to the → business case and to its → business objects and name the → edits, → transitions and → derivations permitted now; the state-dependent transition is only listed for a → valid object (state → ready). What is not listed there is not permitted. Implementation of → HATEOAS and → next best action without a separate hypermedia vocabulary.

Offer (Offert): Offer by the insurer for a calculated → product configuration with validity period and premium guarantee. → Business object of the → application process between calculation and application (assessed state acceptable, transition accept); comes into being by → derivation from a calculation or by → creation without one.

OMDS (Oesterreichischer Makler Datenstandard): An industry standard in Austria for the exchange of insurance data. OMDS 3 defines the services between broker and insurer (so far as SOAP with WSDL/XSD).

OMDS LD (OMDS Linked Data): Working title of this initiative: revision of OMDS 3 with OpenAPI, JSON-LD, SHACL, BPMN and MCP, product and process knowledge at runtime. The steering committee decides whether and under which name this becomes a standard (for example OMDS 4).

Ontology (Ontologie): Formal description of terms and their relationships (here in RDFS/OWL), e.g. what a product node or an instance component is. Together with the → shapes, it forms the normative core of the standard.

OpenAPI: Standard for describing HTTP APIs (operations, paths, data structures). Normative description of the services in this project.

Operation kind (Operationsart): One of the six kinds to which all operations of the standard can be reduced, ordered along two axes – what is transmitted (whole object or delta) and what changes (nothing, new object, content, business state): → inquiry, → creation, → derivation, → replacement, → edit, → transition. For all of them the same four checks apply in the same order: admissibility, → conformity, → completeness, business check of the insurer (see Business Objects and Operations).

Owner (Verantwortlicher): One of the three roles at every → business object: who decides on state and result – as a rule the insurer, for a draft the broker. Set when the object comes into being. The other two roles are → requester and → actor.

Plausibility check (Plausi, Plausibilitätsprüfung): Rule that checks a product configuration for business consistency, e.g. that full casco and partial casco are not included at the same time. The result is a → message.

Policyholder (VN, Versicherungsnehmer): The person or organisation that concludes the contract with the insurer and usually owes the premium.

Premium (Prämie): Price of the insurance cover; calculated by the insurer from a product configuration.

Process knowledge (Prozesswissen): Machine-readable declaration by an insurer stating which of the permitted → process variants it implements. Queried at runtime. Part of the → base profile; does not exist in OMDS 3. Layer insurer of the → process pillar.

Process pillar (Prozesssäule): The pillar of the vocabulary that describes the "how": → business case, → business case type, → business object with → assessed and → set states, → operation kinds, → transitions, → derivations, → next-step links, → process variants and → process knowledge. Five layers: business process core (bc:), vocabulary of the declaration (pk:) and business case types (bct:) lie in the foundation, the process variants of the standard in country-specific standardisation (atpv:), the declaration per insurer in the layer insurer. Counterpart: → structural pillar (see Vocabulary Layers, Business Objects and Operations).

Process variant (Prozessvariante): Permitted way of handling a use case (e.g. storing a draft application on the server or not). The standard lists the variants exhaustively; a predominant variant is the → default case.

Product (Produkt, p:Product): Root element of the coverage tree, corresponds to the OMDS 3 sales product. As a rule set, it defines a priori which product configurations are permitted. Concrete subclass of → product node (see Product Tree and Instance Tree).

Product attribute (Produktattribut, p:ProductAttribute): Property of a product node with type, default value, value range and mandatory flag (e.g. sum insured, deductible).

Product component (Produktbaustein, Produktkomponente, p:ProductComponent): Node of the coverage tree below the product, such as liability or full casco. Its minimum and maximum occurrences define whether it is mandatory or optional. OMDS 3 names the levels differently; the standard only distinguishes between product and product component. Concrete subclass of → product node.

Product configuration (Produktkonfiguration): Abstract generic term for all instances permitted by the product rules. Every product instance that complies with the rules is a product configuration. Calculation, offer, application and contract are specific forms of it, extended by further information depending on the business object (e.g. application questions, persons, payment details). The product configuration describes the common underlying model; whether an instance is a permitted product configuration is checked against the SHACL rules of the product.

Product instance (Produktinstanz, i:Instance with i:InstanceComponent): Specific instance tree that refers to a product and its components via i:basedOn. Every product instance that meets the product rules is a → product configuration.

Product definition (Produktdefinition, p:): The description of a product that is the same for all customers and defined in advance (a priori): coverage tree, cardinalities, attributes with value ranges and rules (Products.ttl, product-specific SHACL shapes). Created by the insurer’s product owners and made retrievable at runtime in the → product knowledge profile. One of the two forms of → product knowledge; counterpart: → product knowledge for the instance.

Product knowledge (Produktwissen): Declarative, machine-readable knowledge about products; core of the product knowledge profile (→ profile; repository name "ProductKnowledge"). Generic term for two forms: the → product definition (general, for all customers) and the → product knowledge for the instance (applied to a specific configuration). Transmitted at runtime so that clients can build and validate configurations themselves.

Product knowledge for the instance (Produktwissen zur Instanz): Part of every response in the → product knowledge profile that contains an instance: which components can be included at a node of the instance (with cardinality and current count) and which attribute values are permitted. Computed from the → product definition and the instance, without a source of its own; consistent with the product-specific SHACL shapes. Not included in the base profile – there the client knows the product itself.

Product node (Produktknoten, p:ProductNode): Abstract generic term for → product and → product component; every node of a coverage tree. Bundles the common properties (name, availability, components, product attributes, terms and conditions). Never occurs itself, only as product or product component; counterpart of the → instance node (see Product Tree and Instance Tree).

Profile (Profil): Defined scope of the standard whose fulfilment the → self-test reports (see Profiles of the Standard). The product knowledge profile builds on the base profile:

Provisional value (vorläufiger Wert, i:provisionalUntil): Value of an → instance attribute that depends on the result of a → business object and is marked provisional until then, with a reference to that object – mostly a → subprocess, which points back to the affected components. Increased deductible until the previous damage inspection, provisional cover until acceptance and premium until the discount approval are forms of this one characteristic; the values are in the product knowledge, not in the subprocess.

Ready (Bereit): General name of the → assessed state in which a → business object is → valid and the state-dependent → transition is among the → next-step links. It has a different name per object type: calculable for the calculation, acceptable for the offer, submittable for the application, reportable for the claim report. Counterpart: → draft (see Business Objects and Operations).

Reference date (Stichtag): Date for which the availability of products is determined (against p:availableFrom/p:availableUntil).

Reference wrapper (Referenz-Wrapper): The → sample insurer with SOAP adapter, which demonstrates every normative operation of both → profiles on top of the existing SOAP services; proof of wrapper capability.

Replacement (Ersetzung): → Operation kind that replaces the content of a → business object with a whole newly transmitted object (Update in OMDS 3 style). The server checks the new content and then assesses the → assessed state anew. Counterpart with delta: → edit (see Business Objects and Operations).

Requester (Veranlasser): One of the three roles at every → business object: who caused the object to come into being – the broker for calculation, offer and application, the insurer for the contract and the → subprocesses it requests. Set when the object comes into being. The other two roles are → owner and → actor.

Risk object (Risikoobjekt, insured interest): The object or person to which the insured risk relates (e.g. a vehicle, a building, a person in life insurance). All risk objects are derived from an abstract base risk object and carry the risk characteristics; an instance keeps them as a list, components refer to them in a directed way (see Risk Objects). Risk objects are part of the product configuration; their risk parameters largely determine the premium.

Risk object rule (Verweisregel): Item of the product knowledge at a product node stating to which kind of → risk objects its components refer, how many references of their own they have and whether the targets must be among the risk objects of the parent component (p:riskObjectRule). A component without a risk object rule has no reference of its own; the risk objects of the parent component apply to it (see Risk Objects).

Risk parameter (Risikoparameter): Premium-relevant properties that bundle all risk characteristics of a case (e.g. date of birth, engine power of a vehicle). They allow calculations without the specific application questions.

Sales product (Verkaufsprodukt): OMDS 3 term for the root element of a product; corresponds to → product.

Sample broker (Muster-Vermittler): Reference implementation of a client on the broker side (module reference/sample-broker).

Sample catalogue of the standard (Beispielkatalog der Norm): Small, informative product catalogue the standard ships with (namespace ex:, folder examples/products/sample/ in the module standard-definition): a motor insurance with mandatory and optional components, attributes of all four types, occurrences and a predecessor relation, a life insurance without components, plus example instances. Belongs to no → example insurer and no → sample insurer; the validation rules of the standard are tested against it. See Product Tree and Instance Tree.

Sample insurer (Muster-Versicherung): Reference implementation of the services on the insurer side (module reference/sample-insurer).

Schema.org: An open vocabulary for structuring data on the web. Serves as a general semantic basis (upper ontology) for things such as persons or organisations.

Self-test (Selbsttest): Tool with which an insurer or a broker checks whether its own implementation complies with the standard; reports the → profiles met and the gaps.

Set state (gesetzter Zustand): State of a → business object that follows from an action, not from the content: through a → transition of the client (submitted, accepted, reported) or through the insurer in its processing (under review, query, accepted, rejected). Counterpart: → assessed state.

SHACL (Shapes Constraint Language): W3C specification for validating RDF graphs (such as JSON-LD). Used to define product rules, mandatory fields and cardinalities formally and machine-readably.

Shape: Single SHACL rule or group of rules, e.g. "a product node must have a name".

Structural pillar (Struktursäule): The pillar of the vocabulary that describes the "what": → product, → product component, → product attribute, → product instance, persons and roles, contract data, code lists and the → shapes for them. Five layers: Schema.org (schema:); in the foundation product definition and product instance (p:, i:), risk objects (risk:), contract data and roles (ct:) and one vocabulary per line of business (e.g. motor:); one vocabulary per line of business in standard Europe and in country-specific standardisation (e.g. atmotor:), there also the Austrian domain terms (at:) and the mapping to OMDS 3 (omds:); product catalogues and additions per insurer. Counterpart: → process pillar (see Vocabulary Layers, Product Tree and Instance Tree).

Subordinate business object (untergeordnetes Geschäftsobjekt, bc:parent): → Business object that is subordinate to a → main object of the same → business case. Has IRI, content, kind, a lifecycle and a version of its own like every business object and is an aggregate of its own; the rule "one current object per type" does not apply to it, the number is declared by the → business case type. A change of the main object can make it invalid; its state enters into the → completeness of the main object. Carried over at the → derivation of the main object as far as declared. First kind: → subprocess (see Subordinate Business Objects).

Subprocess (Nebenprozess, bc:Subprocess): → Subordinate business object that represents, within the → business case, a procedure at the customer, broker, insurer or a third party: discount approval, approval reservation/acceptance, certificate, previous damage inspection, identification of persons, registration. Has kind, business identifier, result, deadline and consequence, is blocking or not and is merged before or after submission. Assessed states open and invalid, set states fulfilled, rejected, aborted, expired. A blocking open subprocess blocks the → transition "submit" of the main object via the → next-step links and → completeness (see Subprocesses).

Transition (Übergang): → Operation kind that changes the business state of the same → business object: submit an application, accept an offer, close a query. Syntax of its own, optionally parameterised (e.g. confirmation token of the → approval gate), but without the content of the object; only permitted in the matching state and only for a → valid object, otherwise rejected without changing anything. Afterwards the object is in the hands of the insurer and immutable for the client. Does not lead to the next object; the → derivation does that (see Business Objects and Operations).

Valid (gültig): → conforming and → complete. Only a valid → business object has the state-dependent → transition among its → next-step links: "calculable" for the calculation, "acceptable" for the offer, "submittable" for the application. These words name the → assessed state → ready per object type.

Vehicle template (Fahrzeugvorlage): Common vehicle type with brand, type, power and list price in an insurer’s catalogue (risk:VehicleTemplate). A suggestion for the vehicle form: choosing one prefills brand, type, power and list price, the fields stay editable; the vehicle does not refer to the template. Knowledge of the insurer, not of the standard (see Vehicle templates of the insurer).

Vocabulary (Vokabular): Related terms with a namespace of their own that belong to exactly one → vocabulary layer and serve exactly one purpose, e.g. the risk objects (risk:) or the Austrian definitions for motor (atmotor:). A layer usually has several vocabularies.

Vocabulary layers (Schichten des Vokabulars): The five levels of generality that each pillar of the vocabulary passes through – general (external vocabularies such as Schema.org), foundation (basic terms and principles for all markets, e.g. the meta-models for product and business process), standard Europe (what applies to all European markets from European law and European standards; currently empty), country-specific standardisation (e.g. Austria) (what OMDS LD defines for an individual country market, e.g. process variants and code lists from OMDS 3) and insurer (declared or added per insurer). Foundation, standard Europe and country-specific standardisation build on one another. Each layer consists of → vocabularies; the layer of a term follows from its vocabulary. Two pillars: → structural pillar and → process pillar; across them the → carriers (see Vocabulary Layers). Not to be confused with the → profiles of the standard.

Wrapper: Component operated by an insurer that offers the new services on top of its existing SOAP services without changing the backend systems: the → sample insurer with a SOAP adapter instead of its own tariff. At the front it provides draft, delta operations, validation report, → product knowledge for the instance and → next steps from the insurer’s → product catalogue; at the back it calls the SOAP services at the → transitions. The same software at every insurer, adapted by declaration, catalogue with OMDS mapping and connection; with an empty catalogue it meets the → base profile, with a catalogue the → product knowledge profile. May be operated without time limit. See Backward Compatibility.

Deviation layer (Abweichungsschicht): South side of a → wrapper holding, as named entries with test case and expiry date, what an insurer’s SOAP implementation does differently from OMDS 3; empty for a conformant endpoint. A deviation is either a declared process variant, an entry in this layer or a gap in the → conformance register; the standard side of the wrapper stays the same at every insurer.