Backward Compatibility
The existing SOAP services remain in operation. An insurer should be able to offer the new services as a wrapper on top of its existing SOAP services without changing its backend systems. The wrapper is hosted by the insurer itself. The base profile remains valid without time limit: an insurer may offer it permanently via a wrapper; there is no switch-off condition.
Since the AI interface is an MCP server in front of the OpenAPI services, the wrapper only has to serve the OpenAPI services. MCP access follows from this without any further effort.
Profiles
Not the whole standard can be mapped onto the old services: the old services do not provide product knowledge – this is the reason for this project. The standard is therefore divided into two profiles, the base profile and the product knowledge profile; the product knowledge profile builds on the base profile. Content, operations and proof of the profiles are described on the page Profiles of the Standard. The base profile can be fulfilled entirely via a wrapper; the product knowledge profile requires a genuine new implementation or a wrapper that adds product knowledge from a formalised product catalogue, and is optional.
A wrapper can meet both profiles:
-
Base profile wrapper: OpenAPI, JSON-LD and MCP; process knowledge as a fixed declaration; in every response the permitted next steps, derived from the status of the SOAP response. It does not provide product knowledge – the client knows the product from documentation, as today. For an AI agent this leaves only the operations that need no product knowledge: retrieving state changes, fetching documents, reading subprocesses, submitting an application.
-
Product knowledge wrapper: in addition, the → product definition from a formalised product catalogue and, in every response, the → product knowledge for the instance (which components can be included where, which values are permitted), plus the draft on the server with the delta operations. This is the wrapper the standard ships as its reference; the base profile wrapper is its special case with an empty catalogue.
Even the base profile offers two advantages over OMDS 3: 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 this from documentation or bilateral agreements. A wrapper that only translates syntax does not solve the core problem, however: the client still has to know the product, and an AI agent cannot use the tool "calculate" without a catalogue, because it requires a complete product instance.
The self-tests report which profiles an insurer meets. The base profile is a lower bound, not an upper bound: an insurer that formalises its product as a catalogue meets the product knowledge profile with the same wrapper.
Structure of the Wrapper
The wrapper is the → sample insurer without its own tariff. Everything the sample insurer holds and computes – the draft, the delta operations, the SHACL validation, the product knowledge for the instance, the next steps – stays in the wrapper; only the calculation and the storage of business objects sit behind an adapter interface. The sample insurer plugs its example tariff into that interface, the wrapper a SOAP adapter to the existing OMDS 3 services. Both are the same software.
The transitions are the hand-over points to SOAP: "calculate" becomes calculateKfz, "accept" becomes
createOfferKfz, "submit" becomes submitApplicationKfz; the tariff inquiry calls calculateKfz without storing
anything; state changes, documents and subprocesses go through the corresponding OMDS operations. Editing the draft
stays in the wrapper and does not need the insurer. Premium per component, messages with element reference, business
case number and status of the SOAP response are mapped onto instance nodes, validation report, business case and the
states of the business object.
It follows that the wrapper holds the draft. Before the first SOAP call the insurer does not know the case; afterwards the business object lives under the business case number at the insurer. The wrapper therefore declares "draft on the server" and needs storage with permissions and a lifetime for drafts. For the AI agent, the typical client without prior knowledge, the draft on the server is the normal form, not the exception.
For the insurer the catalogue is not a throw-away investment: if it later switches to a native implementation, it only replaces the SOAP adapter by an adapter to its backend systems. Catalogue, draft, validation and product knowledge for the instance remain. The wrapper is the first half of the native implementation, not its alternative.
Adapting to the Insurer
The wrapper is the same software at every insurer, a kit built from the server components of the standard that the insurer operates itself and extends if needed. Adapting it consists of three things, none of them code:
| What | Where | Content |
|---|---|---|
Declaration of process knowledge |
Declaration per business case type |
which of the permitted process variants the insurer implements: offer without calculation, application kinds, subprocesses, persistence of the business case |
Product catalogue with OMDS mapping |
The insurer’s catalogue, annotated in the vocabulary |
for each product node and attribute its counterpart in OMDS 3: motor liability to the type |
Connection |
Configuration of the adapter |
endpoint, authentication, insurer number, release |
The line-of-business structure is not configurable and need not be: the motor schema of OMDS 3 is not a generic tree but typed elements with fixed fields. This mapping is the same for all insurers and belongs to the standard; the wrapper carries it as code or data. The mapping of the individual insurer lives in the catalogue, not in the wrapper.
Three Layers and the Places of a Deviation
If a wrapper is configured towards the actual SOAP implementation of an insurer, every deviation from today’s standard – deliberate or an implementation error – threatens to enter the wrapper, and the standard side becomes slightly different per insurer. Bilateral coordination would merely have moved. The wrapper is therefore built in three layers, and deviations must not cross the middle boundary inwards:
-
North side, the standard: business objects, operation kinds, next steps, validation report, MCP. This part is the same code in every installation; only the declaration of process knowledge is configurable, and it may only name variants the standard enumerates exhaustively. The → self-test for insurers runs against this side.
-
Middle, canonical OMDS 3: the mapping of the standard onto OMDS 3 as the reference release writes it, with XSD, specification text and published examples. It is the same for all insurers. What the wrapper produces here is validated against the XSD in both directions: the request before the south side, the response after it.
-
South side, the deviation layer: what the concrete endpoint does differently from the standard – a wrongly assigned status code, an element that must be absent, a message code outside the list – as a transformation between canonical and actual OMDS 3. Each entry is a named record with description, reason, owner, test case and expiry date; for a conformant endpoint the layer is empty.
A deviation has exactly three places:
-
Declared process variant, when the standard permits the variant: no draft on the server, no offer without calculation, a subprocess not offered. The client adapts; this is not a deviation.
-
Entry in the deviation layer, when the difference can be expressed as a transformation. Invisible to the client.
-
Gap, when neither applies, for instance because the insurer does not deliver the application status from which the next step "submit" is derived: the wrapper does not offer the operation, and the insurer is listed with this gap in the → conformance register.
There is no fourth place: the north side never answers "slightly differently" because the backend needs it that way. The kit checks this in its own integration: for every configuration the self-test runs against the north side with recorded SOAP responses.
Product-specific settings that OMDS 3 explicitly permits are not deviations: required optional elements, own components via the generic product component, own codes. They belong in the catalogue and its mapping, not on the south side. This keeps the deviation layer small.
The register of deviations is more than a makeshift. For the first time it makes countable, per insurer, how far the SOAP implementation is from the standard, and it is feedback to the OMDS 3 working group: entries that go back to ambiguous prose of the standard are candidates for exhaustively enumerated variants.
Checks and Product Knowledge
Catalogue and backend can drift apart: the wrapper reports a configuration as conformant, the SOAP service answers with an error. This does not break the model, because the insurer performs all four checks itself anyway and its messages with element reference are passed through as a report at the instance node. It does make testing the catalogue against the backend mandatory, however: the example instances of the catalogue are run through SOAP, and the self-test compares declaration and behaviour. The wrapper thus makes the quality of a catalogue measurable.
Product knowledge does not come from observed SOAP responses. The attribute metadata and product component elements that OMDS 3 can deliver ad hoc in responses are optional, incomplete and tied to generic components; they serve as test data, not as a source. The source is the catalogue from the authoring tool (Tools) or from an export of internal systems; the line-of-business skeleton can be derived from the motor schema.
Design Rules
To keep the base profile wrapper-capable, the standard follows these rules:
-
Server-side persistence is not a uniform feature but a process variant – albeit a very unevenly distributed one: nine out of ten insurers store the draft application on the server, one does not. The standard therefore defines storing on the server as the default case and treats doing without it as a deviation that has to be declared. It must not make persistence mandatory, otherwise the standard cannot be implemented as a wrapper for this insurer.
-
The mapping of SOAP faults and OMDS message codes to HTTP status codes and error objects is defined normatively. Otherwise every wrapper maps differently and no client can rely on it.
-
Status changes continue to be delivered by the insurer; a polling mechanism is not required.
-
The client can query at runtime which profiles an endpoint meets. Without product knowledge it cannot validate locally and has to go back to the insurer.
-
Where the mapping from old to new is lossy or ambiguous, the standard defines what the wrapper delivers.
Design Direction
Wrapper capability is a secondary condition that is checked at the end, not a template. The target model is derived from the use cases and the standardised business processes defined by a parallel working group. If the wrapper determined the design, the result would be SOAP in JSON clothing, and the semantic precision that AI agents need would be lost. A pure protocol wrapper that maps SOAP types one to one to JSON is therefore not conformant.
Wrappers at third parties are not part of the standard: a wrapper at a software house or broker spanning many insurers, or a central wrapper at the association. Authentication, data sovereignty and liability would move to a third party, and it would not deliver product knowledge. A SOAP façade in the opposite direction – OMDS 3 in front of a native server of the new standard, so that existing broker software can still reach an insurer that has switched – is envisaged as soon as the first insurer switches natively, and will then also be built as a kit.
Proof
The requirement "a wrapper must be possible" cannot be tested on its own. It is therefore proven by an artefact: the reference wrapper, the sample insurer with SOAP adapter, which demonstrates every normative operation of both profiles on top of the existing SOAP services – the base profile with an empty catalogue, the product knowledge profile with the catalogue of an example insurer. The self-tests for insurers run against the sample insurer and against the reference wrapper.
The first planned result is a gap analysis for motor insurance: for each new operation, the corresponding SOAP operations and the remaining gaps. It is at the same time the line-of-business mapping of the middle layer.