Process Knowledge

Various transactions take place between broker and insurer: new application, contract change, conversion and claim notification. This page describes the common model that carries all these business case types: a business case is only the bracket, the business objects carry the states, and all services can be reduced to six kinds of operations for which the same checks apply in the same order. What differs per business case type – which objects exist, which transitions, who may trigger them – is declared by the process knowledge. The page Application Process describes the new application in this model. The German terms of the glossary are given in parentheses at first occurrence.

Structure of the Model

The model is described on six pages that build on each other:

Business Case and Business Objects – The business case is the bracket, the business objects carry content and state; they come into being by creation or derivation, can be subordinate to a main object and share the same core characteristics, and a calculation is an inquiry or a business object depending on whether it is kept.
The Six Operation Kinds – Every service is one of six kinds – inquiry, creation, derivation, replacement, edit, transition – along two axes: what is transmitted and what changes.
States of a Business Object – Assessed states (draft, ready) follow from the content, set states from transitions and the insurer’s processing; the general lifecycle applies to every business object.
Checks and Responsibilities – Admissibility, conformance, completeness and the insurer’s business check in a fixed order, and who may trigger which derivation.
Business Case Types – Application process, contract change, conversion and claim handling in the same grid of business objects, states, transitions and derivations.
Subprocesses – Subordinate business objects that represent a procedure at the customer, broker, insurer or a third party: kinds, lifecycle, blocking of submission, declaration in the process knowledge.

Below follows what the standard provides for this model and how the model relates to Domain-Driven Design and hypermedia.

What the Standard Provides for This

Vocabulary for business case types, business objects, their states and the six operation kinds (bc:), so that responses and declarations use the same terms in all types.
Declaration per business case type as process knowledge (pk:): which objects, transitions and derivations exist, who may trigger them, which parameters a transition expects, which inputs a state requires, from when a business case is persisted and jointly editable, whether the insurer holds drafts. The standard lists the permitted variants per type exhaustively; every insurer declares which it implements (process knowledge).
A uniform response form for all operations: the business object concerned in full, its state, the validation report, the business results of the insurer (premium, decision, messages) and the next steps. A client – programmed, smart client or AI agent – continues with every response without a state model of its own.
The application process as the first standardised declaration: the four objects, their states, transitions and derivations, the process variants (offer without calculation, submission without a previous offer, application kinds, calculation history) and the mapping to the OMDS 3 operations calculateKfz, createOfferKfz, createApplicationKfz, submitApplicationKfz.

Profiles

Proposal for how the operation kinds are distributed over the two profiles (not yet decided):

Profile	Operation kinds
Base profile	inquiries, creation, replacement, transition and derivation with the whole object – the OMDS 3 style that a wrapper can map onto the existing SOAP services. Next steps in every response.
Product knowledge profile	additionally edit and delta derivation on the kept draft, product knowledge for the instance in every response. Whether an insurer holds drafts remains a declared property; a wrapper that holds the draft itself may offer the edit in the base profile as well.

Profile

Operation kinds

Base profile

inquiries, creation, replacement, transition and derivation with the whole object – the OMDS 3 style that a wrapper can map onto the existing SOAP services. Next steps in every response.

Product knowledge profile

additionally edit and delta derivation on the kept draft, product knowledge for the instance in every response. Whether an insurer holds drafts remains a declared property; a wrapper that holds the draft itself may offer the edit in the base profile as well.

Relation to Domain-Driven Design and Hypermedia

The model follows two widespread design approaches without adopting their vocabulary: Domain-Driven Design (Evans, Vernon) for the cut of the objects and hypermedia (REST with affordances) for the form of the responses. Readers who know these approaches will find the terms as follows:

Term there	Counterpart in the model	Note
Aggregate	Business object	The consistency boundary: an object with content, state, version and its own lock. The business case is the bracket around several aggregates, not an aggregate itself; between objects there are references (origin, main object), no shared invariants. A subordinate business object (subprocess) is an aggregate of its own as well.
Invariant	Conformity	What must always hold: a non-conforming object is never stored, a non-conforming request changes nothing.
Deferred validation	Completeness	What must hold only at a certain point: a draft may be incomplete, the transition requires completeness.
Factory	Creation, derivation	Objects come into being only through these two kinds, never by sending a finished object to an arbitrary address.
Specification	Shapes of the product knowledge	The admissible form as data, checkable on server and client.
Command–query separation	Inquiry versus the other five kinds	An inquiry keeps nothing and can be repeated at will.
Domain event	Entry of the history	Time, kind of operation, acting party, version; the inquiry "fetch state changes" delivers these events.
Ubiquitous language	Glossary	German leads, the English version fixes the identifiers in the vocabulary.
Bounded context, context map	Layers of the vocabulary, mapping to OMDS 3	Each vocabulary has one purpose and one layer (Vocabulary Layers).
Anti-corruption layer	Wrapper	Translates between an insurer’s existing OMDS 3 services and the model without either side shaping the other.
Affordance	Next step	Every response names what may be done in this state, with operation, target, expected form and responsibility; what is not named is not admissible. A client needs no state model of its own.
Link relation	Navigation link	Where a client can go from an object: business case, predecessor, versions, declaration, product definition – using the IANA standard relations (planned).
Conditional request	Version as ETag	Conditional writing: edit, replacement and transition name the version they presuppose; conditional reading: unchanged objects and product knowledge are not transferred again (planned).
Problem Details	Error response of the admissibility check	The reason as an IRI and the affected objects; the conformity check answers with the validation report instead (planned).

Term there

Counterpart in the model

Note

Aggregate

Business object

The consistency boundary: an object with content, state, version and its own lock. The business case is the bracket around several aggregates, not an aggregate itself; between objects there are references (origin, main object), no shared invariants. A subordinate business object (subprocess) is an aggregate of its own as well.

Invariant

Conformity

What must always hold: a non-conforming object is never stored, a non-conforming request changes nothing.

Deferred validation

Completeness

What must hold only at a certain point: a draft may be incomplete, the transition requires completeness.

Factory

Creation, derivation

Objects come into being only through these two kinds, never by sending a finished object to an arbitrary address.

Specification

Shapes of the product knowledge

The admissible form as data, checkable on server and client.

Command–query separation

Inquiry versus the other five kinds

An inquiry keeps nothing and can be repeated at will.

Domain event

Entry of the history

Time, kind of operation, acting party, version; the inquiry "fetch state changes" delivers these events.

Ubiquitous language

Glossary

German leads, the English version fixes the identifiers in the vocabulary.

Bounded context, context map

Layers of the vocabulary, mapping to OMDS 3

Each vocabulary has one purpose and one layer (Vocabulary Layers).

Anti-corruption layer

Wrapper

Translates between an insurer’s existing OMDS 3 services and the model without either side shaping the other.

Affordance

Next step

Every response names what may be done in this state, with operation, target, expected form and responsibility; what is not named is not admissible. A client needs no state model of its own.

Link relation

Navigation link

Where a client can go from an object: business case, predecessor, versions, declaration, product definition – using the IANA standard relations (planned).

Conditional request

Version as ETag

Conditional writing: edit, replacement and transition name the version they presuppose; conditional reading: unchanged objects and product knowledge are not transferred again (planned).

Problem Details

Error response of the admissibility check

The reason as an IRI and the affected objects; the conformity check answers with the validation report instead (planned).

Not adopted are event sourcing (the history per object suffices), separate read models and a hypermedia envelope such as Hydra, HAL or Siren: next steps and links are part of the JSON-LD graph of the response.