Profiles of the Standard

A profile is a defined scope of the standard that an insurer fulfils. The standard knows two profiles: the base profile and the product knowledge profile. The product knowledge profile builds on the base profile. A profile is neither a layer nor a pillar of the vocabulary (Vocabulary Layers) but cuts across both: it defines what an insurer has to offer to fulfil the profile.

The reason for two profiles: not the whole standard can be mapped onto the existing SOAP services. The old services do not provide product knowledge – this is the reason for this project. An insurer can therefore start with the base profile, which it fulfils via a wrapper, and add the product knowledge profile later or not at all.

The Profiles at a Glance

Profile Content Operation kinds Can be mapped via a SOAP wrapper

Base profile

Processes and instances in AI-capable syntax (OpenAPI, JSON-LD, MCP): calculation, application, conversion, contract change, status notification, documents. In addition, process knowledge: the declaration of which of the standardised process variants the insurer implements.

Inquiries, creation, replacement, transition and derivation with the whole object – the OMDS 3 style. Next steps in every response.

Yes, without changing the backend systems. The wrapper provides the process knowledge as a fixed declaration of the process variants it supports. The base profile remains valid indefinitely.

Product knowledge profile

Base profile plus product knowledge: declarative product model, client-side validation with SHACL constraints, product knowledge for the instance in every response.

in addition, editing and delta derivation at the retained draft.

No, genuine new implementation; optional. A wrapper can fulfil it if it adds product knowledge from internal systems.
The distribution of the operation kinds over the two profiles is a proposal and not yet decided (operation kinds per profile).

Base Profile

The base profile is the lower limit, not an upper limit. Compared with OMDS 3 it offers two advantages: the AI-capable syntax and the process knowledge, which does not exist in OMDS 3. A client or AI agent learns at runtime which process variants an insurer implements instead of taking it from documentation or bilateral agreements.

For the motor application process, the base profile comprises the operations with the whole business object: the tariff inquiry, creation and derivation of offer and application, and the transition "submit" of the application. Each corresponds to an operation of the existing SOAP services (calculateKfz, createOfferKfz, createApplicationKfz, submitApplicationKfz; Mapping to OMDS 3) and can therefore be mapped via a wrapper.

In the base profile the client knows the product from documentation, as today. The base profile does not provide product knowledge.

Product Knowledge Profile

The product knowledge profile adds to the base profile everything the client has to know about the product at runtime:

  • the → product definition as a declarative product model (Product Knowledge),

  • in every response that contains an instance, the → product knowledge for the instance: which components can be included where,

  • the step-by-step editing of a configuration at the draft and the derivation with changes (delta derivation),

  • client-side validation with the SHACL constraints of the product.

The product knowledge profile therefore contains all operations that go beyond the tariff inquiry and creation from the whole object, such as product selection, retrieval of product knowledge and editing at the draft.

Whether an insurer keeps the draft of a configuration on the server remains a declared property of the → business case. A wrapper that keeps the draft itself may offer editing in the base profile as well.

Profiles in the Grid of Pillars and Layers

The profiles cut across the two pillars of the vocabulary:

  • The base profile comprises the process pillar in all layers (without the operation kinds editing and delta derivation) and the structural pillar without the product definition: product instances (i: without i:basedOn), risk objects (risk:), contract data and roles (ct:), the domain terms and lines of business of the standard and Schema.org.

  • The product knowledge profile adds to the structural pillar the product definition (p:) and the product knowledge for the instance, and to the process pillar the editing at the retained draft.

Wrapper and New Implementation

A wrapper can fulfil both profiles (details: Backward Compatibility):

  • A base profile wrapper offers OpenAPI, JSON-LD and MCP, the process knowledge as a fixed declaration and, in every response, the permitted next steps, derived from the status of the SOAP response.

  • A product knowledge wrapper additionally provides the product definition from a formalised product catalogue, in every response the product knowledge for the instance, and the draft on the server with the delta operations; it calls the SOAP services at the transitions.

Both are the same software – the sample insurer with a SOAP adapter – and the base profile wrapper is the special case with an empty catalogue. The base profile is a lower limit: an insurer that formalises its product as a catalogue fulfils the product knowledge profile with the same wrapper. A new implementation is not required for that.

Proof

The → self-tests show which profiles an insurer fulfils and list the gaps. The public conformance register lists which insurer fulfils which profiles. For wrappers, a gap analysis shows which operations of the base profile can be served from the existing WSDL definitions (Tools).

Further Reading