Checks and Responsibilities

Part of Process Knowledge. Admissibility, conformance, completeness and the insurer’s business check in a fixed order, and who may trigger which derivation.

The Four Checks

Every operation passes through the same checks in the same order. The first two never change anything; the third decides depending on the kind whether the object is stored; the fourth is the business check of the insurer.

checks-per-operation

  1. Admissibility (Zulässigkeit). Is the operation allowed in this state of the object, and may the caller execute it? A transition "submit" on an application already submitted, an edit of a handed-over object, an access without authorisation are rejected (HTTP 409 for the state, 403 for the rights, 404 for an unknown object) without anything changing. Admissibility also covers the version: edit, replacement and transition name the version of the object they presuppose (HTTP If-Match); if the object has been changed in the meantime – by another editor or by the insurer –, the server answers with 409 and the current version, and the client reads anew. The error response of the admissibility check (403, 404, 409) names the reason as an IRI from the vocabulary (bc:StateNotAllowed, bc:VersionMismatch, bc:BlockedBySubordinate, bc:IncompleteForTransition), status, title, explanation and the affected objects – for blocking subprocesses their IRIs and states, for a version conflict the current version – in the form of Problem Details (RFC 9457), embedded in JSON-LD. The conformity check, by contrast, answers with the validation report.

  2. Conformity (Konformität). Is the request syntactically correct, does the result satisfy the shapes of the product model, and do the parameters fit? This applies to all kinds, also to the transition and its parameters. A non-conforming request is rejected with HTTP 422 and a validation report without anything changing. A stored object is therefore always conforming.

  3. Completeness (Vollständigkeit). Are all mandatory inputs present that the state requires? For creation, derivation, replacement and edit this is not a condition: an incomplete object is stored as well, the server assesses the state anew (draft or ready), and the response carries the report with every missing input at the node concerned and the next steps. For the transition, completeness is a prerequisite: an incomplete object is rejected with HTTP 409 and a report without anything changing. The completeness of a main object also covers the state of its blocking subordinate objects: the transition "submit" is admissible only once every blocking subprocess is fulfilled; until then the transition is missing from the next steps, and the report names the blocking objects. For the inquiry there is nothing to store; it delivers result and report.

  4. Business check of the insurer (fachliche Prüfung). Premium, underwriting guidelines, cover, plausibility checks – everything the standard does not decide by structure. Its outcome is a result, not a yes or no: a premium, an acceptance decision, a query, messages at the element concerned. It runs at the transition and, where the type provides for it, in the processing by the insurer.

The terms for this are in the glossary: conforming (the product model is satisfied), complete (the mandatory inputs of the state are present), valid (conforming and complete). The server checks every request itself and in full; the client may pre-check with the same shapes, but need not (Solution Approach).

Conformity and completeness are two different kinds of rule: conformity is an invariant – it holds for every stored object at all times, which is why a non-conforming request changes nothing. Completeness is a deferred validation – it has to hold only at the transition, which is why a draft may be stored incomplete and the server says with the assessed state and the report what is still missing (Relation to DDD and Hypermedia).

Responsibilities

A derivation may be triggered by whoever is responsible for the new object:

  • The broker derives what it presents to the customer or submits on the customer’s behalf: calculation → offer, offer → application, existing contract → contract change application, existing contract → conversion application.

  • The insurer derives what it is responsible for: application → contract, contract change application → changed contract, conversion application → new contract, review and settlement of a claim.

At every business object the responsibilities appear as three roles (core characteristics):

  • The requester (Veranlasser) caused the object to come into being: the broker for calculation, offer and application, the insurer for the contract and for the subprocesses it requests.

  • The owner (Verantwortlicher) decides on state and result: as a rule the insurer, for a draft the broker.

  • The actor (am Zug) is who has to act next: the broker at the draft and in the query, the insurer at the submitted application, the customer at the identification, the assessor at the inspection.

Requester and owner follow from the declaration of the derivation and are set when the object comes into being; the actor changes with the state and shows a client or agent uniformly at every object whether it has to act itself or waits.

Transitions are triggered by the client that held the object until then; the set states afterwards are assigned by the insurer. Which transitions and derivations a business case type has, who may trigger them and which parameters a transition expects are declared by the process knowledge per type; the expected form of a parameter is named by the next step as a shape (bc:expects), as today with every operation.