Solution Approach

There are three groups of services:

  • Services to retrieve product knowledge: product properties, permitted configurations and rules.

  • Services to retrieve process knowledge: which of the process variants permitted by the standard an insurer implements.

  • Services to create business objects (calculations, offers, applications, contracts, contract change applications, claim reports), to edit them and to lead them through their states.

The current OMDS 3 services of the application process assume that the client has process and product knowledge programmed into it. The new services provide this information at runtime.

All services are one of six operation kinds (Operationsarten): the first two groups are inquiries – they read or calculate and keep nothing with the insurer –, the third group creates a business object, derives it from a predecessor, replaces or edits its content or changes its business state with a transition. For all kinds the same four checks apply in the same order, and all business case types – application process, contract change, conversion, claim notification – are served with the same kinds. The model is described in Business Objects and Operations; this page only names what follows from it for the interface and the product knowledge.

Interface Technology

  • The business domain is transmitted as a knowledge graph in JSON-LD; vocabulary and constraints are described in RDFS/OWL and SHACL. The Technical Foundations give an introduction to these technologies.

  • The services are defined in OpenAPI.

  • The AI interface is an MCP server in front of the OpenAPI services.

  • Responses contain hypermedia links to the permitted next steps, at the business case and at each of its business objects: which edits, transitions and derivations are allowed now. A client – whether programmed, smart client or AI agent – does not need to know the flow from the documentation, but reads it from the response. What is not listed there is not permitted.

  • All operations respond in the same form: the business object concerned in full, its state, the validation report, the business results of the insurer (premium, decision, messages) and the next steps.

Requirements for the Services

  1. Semantic schemas: Data fields are semantically annotated in a self-explanatory way with types, descriptions and examples.

  2. MCP compatibility: The core functions are available as standardised tools for the Model Context Protocol.

  3. Step-by-step pre-validation: Quick partial checks (e.g. vehicle or previous insurance data) are possible directly during the dialogue. They are an offer to the client, not an obligation: the insurer always performs all checks itself.

  4. Error feedback and next best action: Error messages contain clear instructions that a model can turn directly into questions to the customer. Every response explicitly states the permitted next steps and the mandatory fields they require.

  5. Idempotency and approval gate: Duplicate contracts are reliably prevented. The transition "submit" of the application requires an explicit confirmation token as a parameter (human in the loop).

Product Knowledge

The product model is described declaratively as a knowledge graph (see Product and Product Tree and Insurance Products as Rule Sets). The calculation remains with the insurer. The client can, however, check a configuration itself before submitting it using the supplied SHACL constraints and thus avoid unnecessary round trips.

This pre-validation is not mandatory. An insurer neither has to transfer every check to the client nor may it rely on the client having checked: it performs all checks itself, on every request. Every response can therefore carry messages, at any instance node and any attribute, and one element can carry several messages at once. A client must be able to show them per element, even where it could have run the same check itself.

What follows from a violation depends on which of the four checks it concerns; they run for every operation in the same order:

  1. Admissibility (state of the business object, rights of the caller): an inadmissible operation – submit on an application already submitted, edit a handed-over object – is rejected and changes nothing.

  2. Conformity (component permitted, attribute belongs to the node, value within range, parameters fit): a non-conforming operation is rejected with a validation report and changes nothing. A stored business object is therefore always conforming.

  3. Completeness (mandatory inputs the state requires): for creation, derivation, replacement and edit it is not a condition – an incomplete object is stored as well, the server assesses it as draft, the response lists what is missing and names the next steps that are therefore not yet possible. If the object is valid, the server assesses it as ready (submittable for the application, acceptable for the offer, calculable for the calculation). A transition (calculate, accept, submit) requires completeness and is otherwise rejected without changing anything.

  4. Business check of the insurer (premium, underwriting guidelines, cover, plausibility checks): delivers a result and messages at the element concerned, not a yes or no about the structure.

A client makes this visible: the business object, its assessed state (draft or ready), what is still missing, and which next steps the insurer currently offers.

Draft and Edits (Delta Operations)

Where the insurer holds a business object as a draft itself – it declares this as process knowledge for the business object, today the calculation ("draft at the server") –, a client need not send the whole object with every change (replacement), but can change it with small operations (edits). It creates the business object with the chosen product and the reference date – this brings the business case into being – and receives the draft as the default instance: the sales product, its mandatory components and every attribute with its default. From then on it edits the draft with the delta operations: addComponent includes a component of the product at a node of the draft – together with its mandatory components and its attributes in their defaults –, removeComponent excludes an included component with its subtree again, setAttributeValue sets or removes the value of an attribute; createRiskObject, assignRiskObject and removeRiskObject create risk objects, assign them to components and remove them again (see Risk Objects). Further edits for persons and application questions follow the same pattern.

Every response is the complete business object, not just the changed part, and carries three things with which the client continues without a state model of its own:

  • the validation report of the whole object (mandatory components, mandatory attributes, value ranges) with messages per node and attribute – an incomplete object is stored and reported as such – and the state assessed from it, draft or ready;

  • the product knowledge for the instance: at every node, which components can still be included there, how often, and whether that is permitted right now; at every attribute, the permitted values;

  • the next steps: which edits are allowed on which node now, and at the business object, whether the transition – for the calculation "calculate" – is permitted now. What is not listed there is not permitted.

A non-conforming edit – the component does not belong below this node, the maximum number is reached, the node does not exist – is rejected and changes nothing; the response names the reason in a machine-readable way. Excluding a mandatory component, on the other hand, is a conforming edit: the object becomes incomplete, falls back to the state draft, the report says what is missing, and until then the transition "calculate" is not a next step. This way a mandatory component can be exchanged for another without inventing a contradictory intermediate state. Likewise, an attribute value outside the permitted range is stored and reported at the attribute; only a value that does not fit the datatype of the attribute is rejected.

The sample broker shows the pattern: where the insurer declares "draft at the server", it rebuilds the product tree from the draft after every response – included components as rows, those still includable with "" –, enables "", "−" and "Calculate" only when the next steps name the operation, and shows a rejection as a message at the component concerned. "Calculate" names only the business case: the insurer calculates the draft it holds itself and answers with the premium per component, which stays visible until the next change. Without the declaration it keeps the configuration locally as before and sends it in full for calculation. An AI agent works with the same responses: the next steps tell it which tool it may call next, the product knowledge for the instance tells it with what, and the report tells it what is still missing.

Clients with and without prior knowledge

The standard allows two kinds of clients that serve the same products:

  • A client with prior knowledge loads the product knowledge in advance – product tree, occurrences, attributes with datatype, bounds and default –, builds the configuration itself and sends it in full for calculation; the insurer then validates it. What the product knowledge declares – minimum number of components and risk objects, required attributes, bounds and datatypes – it can check itself beforehand and show with the same messages as the insurer; the insurer’s validation at the calculation is binding. This suits clients that know a product from a business point of view, and it also works without "draft at the server".

  • A client without prior knowledge only knows the base URL of the insurer, the chosen product, the reference date and the names of the operations. Everything else it takes from the latest response: what the components are called, which ones may still be included at which node, which ones are mandatory, which attributes there are and which values are permitted, what is still missing and which next steps are possible now. It requires "draft at the server", changes the business object in small edits and builds its input fields from the permitted values of an attribute (datatype, bounds, required flag, default).

Which kind a client can use with an insurer is stated in the insurer’s declaration of process knowledge. The sample broker contains both: the product tree configurator with prior knowledge and the draft editor without prior knowledge, which additionally shows every call with request and response. An AI agent is the typical client without prior knowledge.

The reference implementation today implements the application process up to the calculation, but does not yet follow the model of business objects: the calculation responds like a tariff inquiry but at the same time sets up an object under a business case id, and the draft status is kept at the business case. The switch to inquiry, creation and assessed states at the business object is the next step (Approach).

Business Case and Next Steps

A business case is the bracket under which the business objects of one transaction lie – in the application process calculation, offer, application and contract. It has no business state of its own; the business objects carry it, as an assessed state from the content (draft, ready) or as a set state from an action (submitted, under review, query, accepted, rejected). The business case carries what the insurer declares as process knowledge about it – whether it keeps it, who may access it, whether third parties edit it jointly –, and with every response it provides the next steps at itself and at its objects. How business objects come into being (creation, derivation), how they change their states (transition) and which business case types exist is described in Business Objects and Operations; the application process as the first example in Application Process.

Process Knowledge

Process knowledge works in the same way as product knowledge: the standard lists the permitted process variants exhaustively, every insurer declares in machine-readable form which of them it implements, and the client adapts to this at runtime. Where one variant clearly predominates, it is the default case; only the deviation then has to be declared.

The declaration is made per business case type: which business objects, transitions and derivations exist, who may trigger them, which parameters a transition expects (such as the confirmation token at submission), which inputs a state requires, from when a business case is persisted and jointly editable, and whether the insurer holds drafts. The application process is the first standardised declaration; contract change, conversion and claim notification follow in the same grid (Business Case Types).

Conformance

Insurers must be able to check whether their services comply with the standard. An evaluation shows whether everything is supported in accordance with the standard or where there are deficits. Brokers must likewise be able to check whether their client supports all features of the standard. Only then can an insurer rely on rolling out a product automatically. The profiles of the standard are described in Profiles of the Standard, the testing tools in Tools.